[Bug middle-end/42919] [4.3/4.4/4.5 Regression] Argument unnecessarily spilled

[matz at gcc dot gnu dot org]

------- Comment #4 from matz at gcc dot gnu dot org  2010-02-01 02:41 -------
Well, actually it depends.  The code generated by 3.4 might theoretically
be slower, because it potentially uses a misaligned stack slot (incoming
stack with -m32 only 4 byte aligned).  With -mpreferred-stack-boundary=2 also
newer compilers use the incoming stack slot instead of copying it around.

When we determined we need a stack slot, the flow is like so: when the slot
alignment (32bits) is not known to be enough for it's declared type (64 bits
here), _and_ the preferred stack alignment (128 per default in new compilers)
is larger than the known slot alignment, then allocate a new stack slot.

"allocate a new stack slot" is what differs between old and new compilers.
New compilers will simply, well, allocate a new slot :)  Old compilers will
only use ADDRESSOF (if the type itself can otherwise be placed into
registers), a kind of deferred stack slot allocation to wait if the 
address really needs to be taken (in new compilers this is always the case,
because we can rely on TREE_ADDRESSABLE).  If it turns out to be necessary,
then it will reuse the stack slot, possibly misaligned (and the latter could
be regarded as bug).

If the 3.4 compiler also would check for alignment in the new way (it only
did so for STRICT_ALIGNMENT targets), it too wouldn't have used the incoming
stack slot.

This additional checking (not only for STRICT_ALIGNMENT targets) came in
as fix for PR18916 (that was after ADDRESSOF was removed already, otherwise
that fix would have affected that code too).

So, I think, everything works as intended, as long as the alignment facts are
as they are:
* long long is 64 aligned
* incoming stack is 32 aligned
* preferred alignment is 128 (and that this matters seems fishy too)

One might argue that this should only matter for STRICT_ALIGNMENT targets,
and therefore that ppc (ref PR18916) is such target.  But that was altivec
code.  And with such code (SSE) x86 also is sort of a STRICT_ALIGNMENT target.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42919