[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned

["mikulas at artax dot karlin dot mff dot cuni dot cz" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #54 from mikulas at artax dot karlin dot mff dot cuni dot cz  2009-09-27 09:03 -------
(In reply to comment #51)

For 4.4, the designers held two wrong assumptions:

1) the incoming stack is always aligned on -mincoming-stack-boundary (wrong for
functions called from assembler or code generated by other compilers).

2) all the variables must be aligned on their alignment (wrong for double, long
double, long long, mmx: the processor may accept them misaligned).

The assumption 1) generates crashing code (for example Seamonkey). The
assumption 2) generates suboptimal code (bug #40667).

The assumption 1) can be trivially quashed with parameter
-mincoming-stack-boundary=2, then the code will be non-crashing, but you will
be hitting problem 2) and the code will be ugly and slow: any function
containing double or long double variable will generate code for stack
realigning and a frame pointer. (for long long this inefficiency was partially
fixed in 4.4.1, but only partially, single long long variables don't trigger
the alignment after 4.4.1 but structures with long long do, see bug #40667).

So: to fix problem 1), gcc should assume that the incoming stack is 4-byte
aligned. To fix problem 2), instead of single alignment, types and variables
should have two alignments: preferred alignment and enforced alignment (so that
you don't realign the stack if there is double on it, but you realign it if
there is 16-byte SSE).


-- 


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