------- 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
