[Bug target/44542] expand_one_stack_var_at may set DECL_ALIGN to a too high value

["matz at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #1 from matz at gcc dot gnu dot org  2010-06-15 11:19 -------
We have a slightly problematic ordering issue here.  Here's what I
think should be made the case:
  DECL_ALIGN should not matter after expansion, we have MEM_ALIGN for that.
  (and for calculating offsets from stack-ptr we can calculate the
   alignment directly)

If that were the case already we wouldn't have the problem of having to
maintain DECL_ALIGN.  Of course the problem is, that MEM_ALIGN is actually
generated from DECL_ALIGN during expansion itself.  It follows that it
actually wouldn't help at all to fixup only DECL_ALIGN after the final
stack alignment is known.  We would also have to walk all RTL and fixup
MEM_ALIGN too (in possibly non-obvious ways).  If we wouldn't do that
but start with minimal DECL_ALIGN we have only managed to produce very
suboptimal code.  On some architecture even so unoptimal as to use unaligned
instructions were aligned ones would be possible.  And we wouldn't necessarily
be able to fixup _that_ after the fact.

Now, the mentioned ordering problem is, that we align the stack only after
all instructions are converted (and hence all stack-vars are expanded).  We
can't do it before, because the necessity for stack-alignment depends on
the actually emitted stack-vars.  And doing it afterwards will lead to the 
need for walking all instructions again, fixing DECL_ALIGN and MEM_ALIGN
(and changing instructions to use more optimal versions of the alignment
now is somehow better).

I think the only correct way is for expand_stack_alignment to align the
stack exactly so that all DECL_ALIGN and MEM_ALIGN entries are correct.
In other words I think it would be a bug for expand_stack_alignment to
generate an actual stack alignment that would lessen the alignment of
stack vars.

To that effect I think I'd rather want to see a reproducer for 4.5/4.6
and fix the bug in expand_stack_alignment (possibly in the target hooks)
than trying to fiddle with the insn chain.

Weren't there some DRAP fixes after 4.4?  I seem to remember some patches
flying by at that time-frame.  Perhaps you can also create a reproducer
for 4.5 just before expand-from-ssa?


-- 


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