On Tue, 2005-07-19 at 22:31, Ian Wienand wrote: > After some investigation I believe this is do with differences between > the alignment of variables on the stack between gcc 3 and 4 and the > ski simulator.
There has been no change to the natural alignment for the variable here. It has always been 4 bytes. There has been a change to the placement of variables into stack slots. This stuff was completely written as part of the tree-ssa work. If gcc-3.4 and earlier, some structures (BLKmode structures) were being over-aligned when allocated to stack slots. They always got the maximum alignment (16 bytes for IA-64) instead of their natural alignment. It isn't clear why. I think this was an accident of implementation. We were basing variable alignment on modes instead of type alignment, and since some BLKmode structures do require max alignment, we had to give it to all of them. In gcc-4.0, we get this right. The variable/type alignment is used to determine the stack alignment needed. If the alignment is less than the stack slot size, then we don't pad to the next stack slot regardless of the size or type or mode of the variable. We only pad to the alignment boundary. This results in smaller frame sizes. In this case though, we end up with the structure being allocated across two stack slots, even though it would fit in one. Again, I think this is an accident of implementation. We might get better code if this structure was allocated to a single stack slot, as then we could use ld8/st8 to move it around. This would be at the expense of a small increase in frame size in general, though we would still have smaller frames than gcc-3.4 and earlier. Probably no one has considered this issue because no one has noticed it before. - To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
