public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: rridge@csclub.uwaterloo.ca (Ross Ridge)
To: gcc@gcc.gnu.org
Subject: Re: A proposal to align GCC stack
Date: Tue, 18 Dec 2007 23:31:00 -0000	[thread overview]
Message-ID: <20071218233125.5586173D25@caffeine.csclub.uwaterloo.ca> (raw)

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 aligned, it just
>performs poorly if it isn't.

Robert Dewar writes:
>First, although for some types, the accesses may work, the optimizer
>is allowed to assume that data is properly aligned, and could possibly
>generate incorrect code ...

That's not enforced by hardware.

>Second, I am pretty sure there are SSE types that require
>alignment at the hardware levell, even on the i386

This isn't a restriction on stack aligment.  It's a restriction on what
kinds of machine types can be accessed on the stack.

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 never generate
code that that would violate this requirement, even in leaf-functions
or transitorily during the prologue/epilogue.

This is different than the proposed ABI_STACK_BOUNDARY macro which defines
the possibily stricter aligment the ABI requires at function entry.  Since
most i386 ABIs don't require a stricter alignment, that has ment that
SSE types couldn't be located on the stack.  Currently you can get around
this problem by changing the ABI using -fperferred-stack-boundary or by
forcing an SSE compatible alignment using -mstackrealign or __attribute__
((force_align_arg_pointer)).  Joey Ye's proposal is another solution
to this problem where GCC would automatically force an SSE compatible
aligment when SSE types are used on the stack.

					Ross Ridge

             reply	other threads:[~2007-12-18 23:31 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-18 23:31 Ross Ridge [this message]
2007-12-19  1:25 ` Robert Dewar
2007-12-19  2:18 ` H.J. Lu
  -- strict thread matches above, loose matches on Subject: below --
2007-12-19 11:52 Ross Ridge
2007-12-19 10:06 Ross Ridge
2007-12-19 15:32 ` H.J. Lu
2007-12-19  9:13 Ross Ridge
2007-12-19 14:30 ` H.J. Lu
2007-12-19  3:51 Ross Ridge
2007-12-19 10:33 ` Andrew Pinski
2007-12-20  9:32   ` Ye, Joey
2007-12-20  9:11 ` Ye, Joey
2008-03-20 20:18 ` Ye, Joey
2007-12-19  1:46 Ross Ridge
2007-12-19  1:00 Ross Ridge
2007-12-19  1:53 ` Ye, Joey
2007-12-19  2:07 ` H.J. Lu
2007-12-18 11:55 Ross Ridge
2007-12-18 16:14 ` H.J. Lu
2007-12-18  4:29 Ross Ridge
2007-12-18  6:15 ` H.J. Lu
2007-12-18  7:50   ` Ye, Joey
2007-12-18 13:52 ` Daniel Jacobowitz
2007-12-18 18:05   ` H.J. Lu
2007-12-18 14:41 ` Robert Dewar
2007-12-18  4:25 Ye, Joey
2007-12-21 20:25 ` Christian Schüler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20071218233125.5586173D25@caffeine.csclub.uwaterloo.ca \
    --to=rridge@csclub.uwaterloo.ca \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).