Andrew Haley wrote: > Ian Lance Taylor writes: > > Andrew Haley <aph-gcc@xxxxxxxxxxxxxxxxxxx> writes: > > > > > Geer Bosch asked "Can't we just explicitly align the stack frame to > > > 128-bits during the function prologue, when we know that there are > > > locals that require such alignment?" This seems so obvious that I > > > can't understand why it hasn't been done. > > > > If you don't trust your startup code, use -mstackrealign or the > > force_align_arg_pointer function attribute. > > > > We don't do it by default because it is slower and most people don't > > need it. > > This doesn't make any sense to me. From what people have been saying > here, using -Os *dealigns* the stack pointer, causing programs using > SSE etc to fail. Do we seriously want this to happen? Is -Os > supposed silently to break programs? > In 32-bit mode, situations have been alleged where the reduced stack alignment of -Os necessary to fit applications with huge call stacks. malloc() for 32-bit linux usually is 8 byte aligned, (4-byte aligned for Windows) so there is another source of difficulty in maintaining greater alignment. Due to inconsistent stack alignments, it is not safe to call a gcc function which uses parallel SSE from a 32-bit Intel compiled function. In 64-bit mode, problem with hard stack size limit seems unlikely, and even Windows ABI specifies 16-byte alignments. We do run into situations where larger than default thread stack size has to be specified, but reduced alignment should not normally be considered. Intel compiler option -Os doesn't tinker with stack alignment.
