Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Ralf Baechle <ralf@linux-mips.org>
To: Andi Kleen <ak@suse.de>
Cc: jh@suse.cz, echristo@redhat.com, hubicka@ucw.cz,
	eager@mvista.com, gcc@gcc.gnu.org, linux-mips@linux-mips.org
Subject: Re: GCC-3.4 reorders asm() with -O2
Date: Mon, 26 Jan 2004 09:36:47 +0100	[thread overview]
Message-ID: <20040126083647.GA28612@linux-mips.org> (raw)
In-Reply-To: <20040125202807.2d786115.ak@suse.de>

On Sun, Jan 25, 2004 at 08:28:07PM +0100, Andi Kleen wrote:

> > > It is.  Ralf already knows about the problem, I think - we leave
> > > markers outside of functions which define an entry point, save some
> > > additional registers to the stack, and try to fall through to the
> > > following function.  If the function gets emitted elsewhere, obviously,
> > > we've lost :)
> > > 
> > > [This is save_static_function...]
> > 
> > I only recently fixed the problem with the save_static() inline function
> > which of course was fragile, speculating on the compiler doing the
> > right thing ...  I'll cook up a fix ...
> 
> You can always use __attribute__((noinline))

Not in this particular case.   save_static's purpose was saving all
caller saved registers into the stack so they can be accessed via the
usual struct pt_regs pointer and to make that work it to be inline before
any change of these registers.  That was a small optimization but it also
was fragile so I removed that.  save_static_function was meant to be
used immediately preceeding a syscall's C function and served the same
purpose.  As the implementation ``knew'' gcc wasn't going to move around
the code just falling though worked fine but again that was fragile.

  Ralf

      reply	other threads:[~2004-01-26 12:10 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4011C72C.613E25@mvista.com>
     [not found] ` <20040124011955.GA12040@nevyn.them.org>
     [not found]   ` <20040124012303.GJ32288@atrey.karlin.mff.cuni.cz>
     [not found]     ` <20040124050849.GB14951@nevyn.them.org>
     [not found]       ` <1075009125.3649.0.camel@dzur.sfbay.redhat.com>
     [not found]         ` <20040125100514.GA8810@kam.mff.cuni.cz>
     [not found]           ` <20040125164758.79373419.ak@suse.de>
2004-01-25 17:03             ` GCC-3.4 reorders asm() with -O2 Daniel Jacobowitz
2004-01-25 18:26               ` Ralf Baechle
2004-01-25 19:28                 ` Andi Kleen
2004-01-26  8:36                   ` Ralf Baechle [this message]

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=20040126083647.GA28612@linux-mips.org \
    --to=ralf@linux-mips.org \
    --cc=ak@suse.de \
    --cc=eager@mvista.com \
    --cc=echristo@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=hubicka@ucw.cz \
    --cc=jh@suse.cz \
    --cc=linux-mips@linux-mips.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