This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: basic asm and memory clobbers

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]