This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: basic asm and memory clobbers
- From: Hans-Peter Nilsson <hp at bitrange dot com>
- To: Segher Boessenkool <segher at kernel dot crashing dot org>
- Cc: Richard Henderson <rth at redhat dot com>, David Wohlferd <dw at LimeGreenSocks dot com>, Andrew Haley <aph at redhat dot com>, Jeff Law <law at redhat dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, rth at gcc dot gnu dot org, pinskia at gcc dot gnu dot org, Sandra Loosemore <sandra at codesourcery dot com>
- Date: Thu, 26 Nov 2015 11:26:02 -0500 (EST)
- Subject: Re: basic asm and memory clobbers
- Authentication-results: sourceware.org; auth=none
- References: <564A4AA5 dot 1080706 at redhat dot com> <564AC155 dot 4040601 at LimeGreenSocks dot com> <564B9CB1 dot 1060001 at redhat dot com> <564E762B dot 6070705 at LimeGreenSocks dot com> <564EF338 dot 4030703 at redhat dot com> <564EF7FF dot 1070107 at LimeGreenSocks dot com> <564F008B dot 8040703 at redhat dot com> <564F1436 dot 2060005 at LimeGreenSocks dot com> <564F1A7D dot 9050607 at redhat dot com> <alpine dot BSF dot 2 dot 02 dot 1511260518001 dot 40802 at arjuna dot pair dot com> <20151126123540 dot GA21046 at gate dot crashing dot org>
On Thu, 26 Nov 2015, Segher Boessenkool wrote:
> On Thu, Nov 26, 2015 at 05:30:48AM -0500, Hans-Peter Nilsson wrote:
> > On Fri, 20 Nov 2015, Richard Henderson wrote:
> > > I'd be perfectly happy to deprecate and later completely remove basic asm
> > > within functions.
> >
> > We've explictly promised (directed to kernel people IIRC) that
> > the empty basic asm; 'asm ("")', has forward-compatible
> > outlining magic, so people would not have to keep adding
> > ever-new attributes like noinline,noclone to avoid finding their
> > functions "spilling over", so please exclude that. To wit, from
> > extend.texi:
> >
> > @item noinline
> > @cindex @code{noinline} function attribute
> > This function attribute prevents a function from being considered for
> > inlining.
> > @c Don't enumerate the optimizations by name here; we try to be
> > @c future-compatible with this mechanism.
> > If the function does not have side-effects, there are optimizations
> > other than inlining that cause function calls to be optimized away,
> > although the function call is live. To keep such calls from being
> > optimized away, put
> > @smallexample
> > asm ("");
> > @end smallexample
> >
> > @noindent
> > (@pxref{Extended Asm}) in the called function, to serve as a
> > special
> > side-effect.
>
> Any asm without outputs (including basic asm) is volatile, so it can
> not be optimised away. Putting an empty asm in a noinline function
> should always work as you want, it's not because it is basic asm.
I know, the point is that we've promised the above and we
shouldn't back down on this mechanism to instead deprecate and
warn about it, as seems to be the direction.
This happens to be expressed as a basic asm and was chosen
because the right things happen regarding backwards-
compatibility. More care has to be taken for forward-
compatibility. I'm a bit worried that it still works only
because of happenstance.
I know what (I hope) you're thinking but it's hard to produce a
test-case that fails when a future yet unknown optimization
causes "spill-over", but I can imagine a quick return-path
seeming inlinable in LTO.
brgds, H-P