Mail Archives: cygwin-developers/2001/11/02/16:58:11
On Fri, Nov 02, 2001 at 04:09:47PM -0500, Earnie Boyd wrote:
>Christopher Faylor wrote:
>>
>> I just added the -mpreferred-stack-boundary=2 option to Makefile.common.
>> Is there a good reason not to do this? From the description in
>> gcc.info, it seems like the cases that they are talking about don't
>> affect the cygwin part of things, although it would conceivably be iffy
>> to use this switch in the newlib.
>>
>> The code size reduction is noticeable.
>>
>
>Hmm... In my use of this switch I set the value to 8. I did this based
>on the documentation for this switch in the info file.
>
><info>
>`-mpreferred-stack-boundary=NUM'
> Attempt to keep the stack boundary aligned to a 2 raised to NUM
> byte boundary. If `-mpreferred-stack-boundary' is not specified,
> the default is 4 (16 bytes or 128 bits).
>
> The stack is required to be aligned on a 4 byte boundary. On
> Pentium and PentiumPro, `double' and `long double' values should be
> aligned to an 8 byte boundary (see `-malign-double') or suffer
> significant run time performance penalties. On Pentium III, the
> Streaming SIMD Extention (SSE) data type `__m128' suffers similar
> penalties if it is not 16 byte aligned.
>
> To ensure proper alignment of this values on the stack, the stack
> boundary must be as aligned as that required by any value stored
> on the stack. Further, every function must be generated such that
> it keeps the stack aligned. Thus calling a function compiled with
> a higher preferred stack boundary from a function compiled with a
> lower preferred stack boundary will most likely misalign the
> stack. It is recommended that libraries that use callbacks always
> use the default setting.
>
> This extra alignment does consume extra stack space. Code that is
> sensitive to stack space usage, such as embedded systems and
> operating system kernels, may want to reduce the preferred
> alignment to `-mpreferred-stack-boundary=2'.
></info>
>
>The bits on pentium suggest that I didn't want 2, I don't have results
>for tests using 8 bit it felt faster.
From my reading of the above, setting this to 8 would result in aligning
things on a 64 byte (2**8) boundary. I don't think that is necessary.
Regardless, since the code in the winsup directory doesn't pass doubles
or long doubles around, I don't think there is any reason to force the
alignment for this eventuality. It appears that the same thing is true
of the linux kernel, which uses the same option. That's actually where
I got the idea for this.
cgf
- Raw text -