public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Craig Burley <burley@gnu.org>
To: pcg@goof.com
Cc: egcs@cygnus.com, law@cygnus.com
Subject: Re: x86 double alignment (was egcs-1.1 release schedule)
Date: Thu, 25 Jun 1998 21:48:00 -0000	[thread overview]
Message-ID: <199806251615.MAA12029@melange.gnu.org> (raw)
In-Reply-To: <19980624192457.45730@cerebro.laendle>

>The original patch turned on -mstack-align-double, which I thought is safe,
>but it isn't. I got a report from a windows user that it breaks most windows
>function semantics, as these functions deallocate the stack themselves. In
>this case, -mstack-align-double will break the program.

Wait, how can these functions deallocate the stack themselves when
the *caller* also is deallocating the stack, as is normally the
case for x86-ABI code?  Aren't these functions essentially violating
the ABI in a way the compiler producing code that calls them *must*
know about?

What I haven't looked into yet is whether subtracting 4 from %esp
before pushing args might upset some varargs/stdargs implementation
on the callee side (that the caller doesn't know about), i.e. if
that can even happen.

>If we had -mstack-align-double in egcs, maybe glibc could compile _some_ functions
>(like qsort or __libc_start) with it, so the problem of combine breaking code
>is solved, so we can either
>
>- document that -mno-stack-align-double should be used when linking against third-party-libs
>- not making it on by default.

If it's not on by default, it's of only limited benefit, though that'd
still take care of lots of Fortran users who are willing to learn about
and use an option like -mstack-align-double.

My feeling is that if -mstack-align-double doesn't break the ABI,
then make it the default.  Any bugs resulting from this are thus
likely to be because *other* code breaks the ABI.  Our compiler
should be "told" about those codes explicitly anyway, via attributes
or something.

>there are also speed issues, i.e. in integer-only programs, -mstack-align-double
>slows down code (a bit), so it should probably be disabled anyway.

I was thinking earlier this week that, for example, the Linux kernel
perhaps would run faster if -mno-stack-align-double was specified
for compiling it.

But, the problem is that if we don't make -mstack-align-double the
default, lots of code that uses `double' will not get proper
alignment and will continue have *big* performance degradation.

>-marg-align-double never worked, due to limitations in calls.c (FUNCTION_ARG_BOUNDARY
>is effectively ignored on calls, but not within the called function), and
>breaks the abi, and was thus always optional. (it would align doubles in the
>argument area, this _severely_ breaks the abi, of course)

Yup, we pretty much ended up concluding this (I should say, I finally
understood what others were saying).

        tq vm, (burley)

  parent reply	other threads:[~1998-06-25 21:48 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-06-18  1:32 egcs-1.1 release schedule Jeffrey A Law
1998-06-19  9:02 ` Gerald Pfeifer
1998-06-19 23:47   ` Jeffrey A Law
1998-06-19 11:57 ` Dave Love
1998-06-21 21:43   ` Craig Burley
1998-06-21 23:07   ` Jeffrey A Law
1998-06-22  5:19     ` David S. Miller
1998-06-22 12:04       ` Dave Love
1998-06-22 13:45       ` Toon Moene
1998-06-22 22:29         ` Jeffrey A Law
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-22 12:04     ` egcs-1.1 release schedule Dave Love
1998-06-23  3:32       ` Craig Burley
1998-06-23  3:32       ` Jeffrey A Law
1998-06-23  9:29         ` H.J. Lu
1998-06-24 17:12           ` x86 double alignment (was egcs-1.1 release schedule) Marc Lehmann
1998-06-25  0:25             ` Jeffrey A Law
1998-06-28 18:02               ` Marc Lehmann
1998-06-25 12:33             ` PÃ¥l-Kristian Engstad
1998-06-28 18:02               ` Marc Lehmann
1998-06-25 21:48             ` Craig Burley [this message]
1998-06-25 18:53               ` Jeffrey A Law
1998-06-28 22:41               ` Marc Lehmann
1998-06-29  5:20                 ` Martin Kahlert
1998-06-29 11:08                   ` Jeffrey A Law
1998-06-29 19:43                   ` Craig Burley
1998-06-29 20:41                 ` Craig Burley
1998-06-30  0:42                   ` Jeffrey A Law
1998-06-30  8:19                     ` gcc2 merge H.J. Lu
1998-06-30 19:49                       ` Jeffrey A Law
1998-06-30  4:50                 ` x86 double alignment (was egcs-1.1 release schedule) Jeffrey A Law
1998-06-22 12:04     ` ix86 `double' alignment (was " 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
1998-06-20  6:41 ` egcs-1.1 release schedule Gabriel Dos Reis
1998-06-20  9:22   ` Joe Buck
1998-06-20 15:36     ` Mark Mitchell
1998-06-21  0:07   ` Jeffrey A Law
1998-06-26  7:16 x86 double alignment (was egcs-1.1 release schedule) Michael Meissner

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=199806251615.MAA12029@melange.gnu.org \
    --to=burley@gnu.org \
    --cc=egcs@cygnus.com \
    --cc=law@cygnus.com \
    --cc=pcg@goof.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).