-- 0. MOTIVATION --
Some local variables (such as of __m128 type or marked with alignment
attribute) require stack aligned at a boundary larger than the default
stack
boundary. Current GCC partially supports this with limitations. We are
proposing a new design to fully solve the problem.
-- 1. CU
Ye, Joey writes:
>i. STACK_BOUNDARY in bits, which is enforced by hardware, 32 for i386
>and 64 for x86_64. It is the minimum stack boundary. It is fixed.
Strictly speaking by the above definition it would be 8 for i386.
The hardware doesn't force the stack to be 32-bit aligned, it just
performs p
On Mon, Dec 17, 2007 at 11:25:35PM -0500, Ross Ridge wrote:
> Ye, Joey writes:
> >i. STACK_BOUNDARY in bits, which is enforced by hardware, 32 for i386
> >and 64 for x86_64. It is the minimum stack boundary. It is fixed.
>
> Strictly speaking by the above definition it would be 8 for i386.
> The h
inal Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of H.J. Lu
Sent: 2007年12月18日 13:17
To: Ross Ridge
Cc: gcc@gcc.gnu.org
Subject: Re: A proposal to align GCC stack
On Mon, Dec 17, 2007 at 11:25:35PM -0500, Ross Ridge wrote:
> Ye, Joey writes:
> >i. STACK_BOUNDAR
Ross Ridge writes:
> This section doesn't make sense to me. The force_align_arg_pointer
> attribute and -mstackrealign assume that the ABI is being
> followed, while the -fpreferred-stack-boundary option effectively
"H.J. Lu" writes
> According to Apple engineer who implemented the -mstackrealig
Ross Ridge wrote:
Ye, Joey writes:
i. STACK_BOUNDARY in bits, which is enforced by hardware, 32 for i386
and 64 for x86_64. It is the minimum stack boundary. It is fixed.
Strictly speaking by the above definition it would be 8 for i386.
The hardware doesn't force the stack to be 32-bit aligned
On Mon, Dec 17, 2007 at 11:25:35PM -0500, Ross Ridge wrote:
> >// Reserve two stack slots and save return address
> >// and previous frame pointer into them. By
> >// pointing new ebp to them, we build a pseudo
> >// stack for unwinding
>
> Hmmm... I don't know much about the DWARF unwind in
On Tue, Dec 18, 2007 at 03:39:42AM -0500, Ross Ridge wrote:
> >> changes the ABI. According your defintions, I would think
> >> that INCOMING should be ABI_STACK_BOUNDARY in the first case,
> >> and MAX(ABI_STACK_BOUNDARY, PREFERRED_STACK_BOUNDARY) in the second.
> >
> > That isn't true since some
On Tue, Dec 18, 2007 at 08:47:35AM -0500, Daniel Jacobowitz wrote:
> On Mon, Dec 17, 2007 at 11:25:35PM -0500, Ross Ridge wrote:
> > >// Reserve two stack slots and save return address
> > >// and previous frame pointer into them. By
> > >// pointing new ebp to them, we build a pseudo
> > >//
Ye, Joey writes:
>i. STACK_BOUNDARY in bits, which is enforced by hardware, 32 for i386
>and 64 for x86_64. It is the minimum stack boundary. It is fixed.
Ross Ridge wrote:
>Strictly speaking by the above definition it would be 8 for i386.
>The hardware doesn't force the stack to be 32-bit aligne
Ross Ridge wrote:
> The -fpreferrred-stack-boundary flag currently generates code that
> assumes the stack aligned to the preferred alignment on function entry.
> If you assume a worse incoming alignment you'll be aligning the stack
> unnecessarily and generating code that this flag doesn't require
Ross Ridge wrote:
Ye, Joey writes:
i. STACK_BOUNDARY in bits, which is enforced by hardware, 32 for i386
and 64 for x86_64. It is the minimum stack boundary. It is fixed.
Ross Ridge wrote:
Strictly speaking by the above definition it would be 8 for i386.
The hardware doesn't force the stack t
Robert Dewar writes:
>Well if we have local variables of type float (and we have specified
>use of SSE), we are in trouble, no?
Non-vector SSE instructions, like the ones that operate on scalar floats,
don't require memory operands to be aligned.
Ross Ridge
Ross Ridge wrote:
> I'm currently using -fpreferred-stack-boundary without any trouble.
> Your proposal would in fact generate code to align stack when it's not
> necessary. This would change the behaviour of
-fpreferred-stack-boundary,
> hurting performance and that's unacceptable to me.
This p
On Tue, Dec 18, 2007 at 06:31:26PM -0500, Ross Ridge wrote:
> Ross Ridge wrote:
> > The -fpreferrred-stack-boundary flag currently generates code that
> > assumes the stack aligned to the preferred alignment on function entry.
> > If you assume a worse incoming alignment you'll be aligning the stac
On Tue, Dec 18, 2007 at 06:31:25PM -0500, Ross Ridge wrote:
> Ye, Joey writes:
> >i. STACK_BOUNDARY in bits, which is enforced by hardware, 32 for i386
> >and 64 for x86_64. It is the minimum stack boundary. It is fixed.
>
> Ross Ridge wrote:
> >Strictly speaking by the above definition it would
Ross Ridge wrote:
> I'm currently using -fpreferred-stack-boundary without any trouble.
> Your proposal would in fact generate code to align stack when it's
> not necessary. This would change the behaviour of
> -fpreferred-stack-boundary, hurting performance and that's unacceptable
> to me.
Ye, J
H.J. Lu writes:
> What value did you use for -mpreferred-stack-boundary? The x86 backend
> defaults to 16byte.
On Windows the 16-byte default pretty much just wastes space, so I use
-mpreferred-stack-boundary=2 where it might make a difference. In the
case where I wanted to use SSE vector instruc
Ross Ridge writes:
> As I mentioned later in my message STACK_BOUNDARY shouldn't be defined in
> terms of hardware, but in terms of the ABI. While the i386 allows the
> stack pointer to bet set to any value, by convention the stack pointer
> is always kept 4-byte aligned at all times. GCC should
On 12/18/07, Ross Ridge <[EMAIL PROTECTED]> wrote:
> Look at it another way. Lets say you were compiling x86_64 code with
> -fpreferred-stack-boundary=3, an 8-byte PREFERRED alignment.
Can we stop talking about x86/x86_64 specifics issues here? I have an
use case for the PowerPC side of the Cell
Andrew Pinski writes:
> Can we stop talking about x86/x86_64 specifics issues here?
No.
>I have an use case for the PowerPC side of the Cell BE for variables
>greater than the normal stack boundary alignment of 16bytes. They need
>to be 128byte aligned for DMA transfering to the SPUs.
>
>I alrea
Thanks for Ross and HJ's comments. Here is updated proposal:
Changes:
- value of REQUIRED_STACK_BOUNDARY of leaf function
- value of INCOMING_STACK_BOUNDARY
-- 0. MOTIVATION --
Some local variables (such as of __m128 type or marked with alignment
attribute) require stack aligned at a boundary la
On Wed, Dec 19, 2007 at 04:12:55AM -0500, Ross Ridge wrote:
>
> I'm suggesting a different defintion of STACK_BOUNDARY which wouldn't,
> if strictly followed, result STACK_BOUNDARY being defined as 8 on
> the i386. The i386 hardware doesn't enforce a minimum alignment on the
> stack pointer.
On
On Wed, Dec 19, 2007 at 04:12:59AM -0500, Ross Ridge wrote:
>
> >STACK_BOUNDARY is the minimum stack boundary. MAX(STACK_BOUNDARY,
> >PREFERRED_STACK_BOUNDARY) == PREFERRED_STACK_BOUNDARY. So the question is
> >if we should assume INCOMING == PREFERRED_STACK_BOUNDARY in all cases:
>
> Doing this
Ye, Joey writes:
>> This proposal values correctness at first place. So when compile
can't
>> make sure a function is only called from functions with the same or
bigger
>> preferred-stack-boundary, it will conservatively align the stack. One
>> optimization is to set INCOMING = PREFERRED for local
Pinski
Sent: 2007年12月19日 18:07
To: Ross Ridge
Cc: gcc@gcc.gnu.org
Subject: Re: A proposal to align GCC stack
On 12/18/07, Ross Ridge <[EMAIL PROTECTED]> wrote:
> Look at it another way. Lets say you were compiling x86_64 code with
> -fpreferred-stack-boundary=3, an 8-byte PREFERRED alignm
Ye, Joey intel.com> writes:
>
Please go forward with this idea!
The current implementation of force_align_arg_pointer has never worked for me.
I have a DLL which may be called by code out of my control and I already have
manual stub functions to align the stack. I would love to rely on compile
Ross, Christian,
Here are the patches to implement the idea we discussed before. Can you
take a look at it or try it?
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01200.html
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01199.html
Thanks - Joey
Christian Schüler writes:
> Please go forward with this idea!
> The current implementation of force_align_arg_pointer has never worked for me.
This proposal should solve your problem. But to comfirm, I'd like to know the
root cause. force_align_arg_pointer should have guaranteed 16 bytes align.
29 matches
Mail list logo
