https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51017
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Known to work| |4.3.4
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Target Milestone|--- |4.8.5
Summary|GCC 4.6 performance |[4.8/4.9/5 Regression] GCC
|regression (vs. 4.4/4.5), |performance regression (vs.
|PRE increases register |4.4/4.5), PRE increases
|pressure |register pressure too much
Known to fail| |4.8.3, 4.9.2, 5.0
--- Comment #20 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Alexander Peslyak from comment #19)
> (In reply to Alexander Peslyak from comment #17)
> > Should we create a new bug for the unnecessary and non-optional use of
> > unaligned load instructions for source code like this, or is this considered
> > the new intended behavior despite of the major slowdown on such CPUs?
> > (Presumably not only for JtR. I'd expect this to affect many programs.)
>
> Upon further analysis, I now think that this was my fault, and (presumably)
> not common in other programs. What I had was differing definition vs.
> declaration, so a bug. The lack of alignment specification in the
> declaration of the struct essentially told (newer) GCC not to assume
> alignment - to an extent greater than e.g. a pointer would. As far as I can
> tell, GCC does not currently produce unaligned load instructions (so assumes
> that SSE* vectors are properly aligned) when all it has is a pointer coming
> from another object file. I think that's the common scenario, whereas mine
> was uncommon (and incorrect).
Yes. Note that we are trying to be more forgiving to users here and do not
exploit undefined behavior fully.
> So let's focus on PRE only.
Ok. There are related bugreports for that I think.
