public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: john@feith.com (John Wehle)
To: law@cygnus.com
Cc: burley@gnu.org, d.love@dl.ac.uk, egcs@cygnus.com,
	davem@dm.cobaltmicro.com
Subject: Re: ix86 double alignment (was Re: egcs-1.1 release schedule)
Date: Wed, 24 Jun 1998 17:12:00 -0000	[thread overview]
Message-ID: <199806242143.RAA15394@jwlab.FEITH.COM> (raw)

> It's an interesting question to think about.  HP recommends a 64byte
> alignment for the stack on PAs.  It has some *really* nice benefits
> as far as the dcache is concerned.  And until about a year ago we
> actually followed that guideline -- by setting STACK_BOUNDARY appropriately :-)
> 
> That's how I know about the problems that combine will cause if you
> end up with a mis-aligned stack pointer relative to STACK_BOUNDARY.
> It turned out the crt0 code on hpux10 only provided 8 byte alignment
> for the stack pointer.  Opps.

What about defining PREFERRED_STACK_BOUNDARY to mean the optimal stack
alignment and having it default to STACK_BOUNDARY?  Then change the
places which align the stack based on STACK_BOUNDARY to use
PREFERRED_STACK_BOUNDARY.  Leave code which implements optimizations
(and records the stack alignment) based on STACK_BOUNDARY alone.  This
way gcc will attempt to align the stack based on PREFERRED_STACK_BOUNDARY
and assume STACK_BOUNDARY when implementing optimizations which should
be safe (assuming that PREFERRED_STACK_BOUNDARY >= STACK_BOUNDARY is
enforced).

I known ... I've probably oversimplified the issue. :-)

-- John
-------------------------------------------------------------------------
|   Feith Systems  |   Voice: 1-215-646-8000  |  Email: john@feith.com  |
|    John Wehle    |     Fax: 1-215-540-5495  |                         |
-------------------------------------------------------------------------


             reply	other threads:[~1998-06-24 17:12 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-06-24 17:12 John Wehle [this message]
1998-06-24 21:23 ` Jeffrey A Law
  -- strict thread matches above, loose matches on Subject: below --
1998-06-23 10:23 ix86 `double' " John Wehle
1998-06-23 14:56 ` Craig Burley
1998-06-23 22:55 ` Jeffrey A Law
1998-06-23  3:32 ix86 double " John Wehle
1998-06-23 15:06 ` Craig Burley
1998-06-23 22:55   ` Jeffrey A Law
1998-06-24 10:08   ` Dave Love
1998-06-24 21:23     ` Jeffrey A Law
1998-06-22  5:19 egcs-1.1 release schedule David S. Miller
1998-06-22 18:20 ` ix86 double alignment (was Re: egcs-1.1 release schedule) Craig Burley
1998-06-23  3:32   ` David S. Miller
1998-06-23  6:30     ` Craig Burley
1998-06-23  3:32   ` Jeffrey A Law
1998-06-23  5:13     ` Craig Burley
1998-06-21 23:07 egcs-1.1 release schedule Jeffrey A Law
1998-06-22 12:04 ` ix86 `double' alignment (was Re: egcs-1.1 release schedule) Craig Burley
1998-06-23  3:32   ` Jeffrey A Law
1998-06-23  5:13     ` Craig Burley
1998-06-24  2:28       ` Jeffrey A Law
1998-06-24 14:50         ` Craig Burley
1998-06-25  0:25           ` Jeffrey A Law
1998-06-25  9:59             ` Tim Hollebeek
1998-06-28 18:01             ` Marc Lehmann

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=199806242143.RAA15394@jwlab.FEITH.COM \
    --to=john@feith.com \
    --cc=burley@gnu.org \
    --cc=d.love@dl.ac.uk \
    --cc=davem@dm.cobaltmicro.com \
    --cc=egcs@cygnus.com \
    --cc=law@cygnus.com \
    /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).