On 11/26/2015 8:26 AM, Hans-Peter Nilsson wrote:
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.
That is indeed the direction I am heading unless someone stops me.
I was not aware of this magic. Thanks for pointing it out. To be
clear, wouldn't asm("":) have the same effect?
Since we have committed to this, we don't want to change it lightly.
Also, looking at existing inline asm, this is probably one of the most
common uses. Allowing this exception will probably ease the migration,
even if it makes the docs a little clunkier.
So how about this:
1) Change the docs to say asm("":), so future coders will do "the right
thing."
2) Allow the exception for v6.
3) Re-evaluate if-and-when we continue with the deprecation process.
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.
dw
