How to stop gcc from not calling noinline functions

How to stop gcc from not calling noinline functions

[Hans-Peter Nilsson]

Also known as "nooo, it's not *inlined*, it's just the call
being removed because the called function was found to be
pure/const". :)

This happens when you try to synthesize executable test-cases
and you need e.g. a call with such-and-such parameters, but the
called function doesn't do anything; it's the caller you care
about.  You need the call, and can't just leave the called
function undefined.  But such a stub function called in the same
compilation unit, may surprisingly not be called, *even if you
declare it __attribute ((__noinline__))*, and when you look at
*just* the call site, the cause is not just that the call is
dead as-is.  It's a bit confusing until you remember or are
being told that all functions are analyzed for pure-or-constness
and the noinline attribute doesn't have say in what happens
next.  The remedy is -fno-ipa-pure-const or sticking a naked
asm ("") in the stub function.  At least, that works for now.

I'm testing the waters for a more well-defined solution.  IMHO a
construct is needed for e.g. such test-cases to stand more of a
chance to not turn into NOPs with the next smart
not-inlined-but-you-can't-tell-the-difference optimization.
There appears to be a use for this in the Linux kernel too
(kprobe?), and there's a (timing) use case in PR 16922 too.  If
you agree, how should it be done?

Redefine the noinline attribute to also stop gcc from analyzing
such functions and "keep them called" (my favorite, because as a
user, you can't really tell the call-removed effect apart from
being-inlined).

Or, another attribute.  Name?  Maybe "always_extern", but I'm
not sure that's as intuitive and obvious as "noinline".  I don't
like the perhaps immediately obvious "always_call", because I
think the calls should be deleted if the call-site is dead, just
not for reasons found out from analysis of the called function,
and the name suggests otherwise (alternatively, an implementation
to stop dead-code elimination would be troublesome and useless. :)

Or, just make "noinline" functions that are also "extern" stay
extern and called.

(Yeah, new attributes "impure" and/or "nonconst" would solve
this, but only for IPA and there's already the existing option
and asm I mentioned.  And if you say different files/compilation
units, I say LTO.)

brgds, H-P

Re: How to stop gcc from not calling noinline functions

[kai-gcc]

On Sat, Jan 12, 2008 at 07:20:03AM +0100, Hans-Peter Nilsson wrote:

> Or, another attribute.  Name?  Maybe "always_extern", but I'm
> not sure that's as intuitive and obvious as "noinline".  I don't
> like the perhaps immediately obvious "always_call", because I
> think the calls should be deleted if the call-site is dead, just
> not for reasons found out from analysis of the called function,
> and the name suggests otherwise (alternatively, an implementation
> to stop dead-code elimination would be troublesome and useless. :)

volatile.

That seems to express exactly the right spirit: you can
dead-code-eliminate it, but if you don't, call it exactly as the source
code suggests.

I don't know if the language standards already associate an incompatible
meaning to it in this context; if so, just define an attribute with that
name.

Re: How to stop gcc from not calling noinline functions

[Paolo Bonzini]

> (Yeah, new attributes "impure" and/or "nonconst" would solve
> this, but only for IPA and there's already the existing option
> and asm I mentioned.  And if you say different files/compilation
> units, I say LTO.)

I think the asm is your best bet.

Paolo

Re: How to stop gcc from not calling noinline functions

[Richard Guenther]

On Jan 12, 2008 7:20 AM, Hans-Peter Nilsson <hans-peter.nilsson@axis.com> wrote:
> Also known as "nooo, it's not *inlined*, it's just the call
> being removed because the called function was found to be
> pure/const". :)
>
> This happens when you try to synthesize executable test-cases
> and you need e.g. a call with such-and-such parameters, but the
> called function doesn't do anything; it's the caller you care
> about.  You need the call, and can't just leave the called
> function undefined.  But such a stub function called in the same
> compilation unit, may surprisingly not be called, *even if you
> declare it __attribute ((__noinline__))*, and when you look at
> *just* the call site, the cause is not just that the call is
> dead as-is.  It's a bit confusing until you remember or are
> being told that all functions are analyzed for pure-or-constness
> and the noinline attribute doesn't have say in what happens
> next.  The remedy is -fno-ipa-pure-const or sticking a naked
> asm ("") in the stub function.  At least, that works for now.
>
> I'm testing the waters for a more well-defined solution.  IMHO a
> construct is needed for e.g. such test-cases to stand more of a
> chance to not turn into NOPs with the next smart
> not-inlined-but-you-can't-tell-the-difference optimization.
> There appears to be a use for this in the Linux kernel too
> (kprobe?), and there's a (timing) use case in PR 16922 too.  If
> you agree, how should it be done?
>
> Redefine the noinline attribute to also stop gcc from analyzing
> such functions and "keep them called" (my favorite, because as a
> user, you can't really tell the call-removed effect apart from
> being-inlined).

No. ;)

> Or, another attribute.  Name?  Maybe "always_extern", but I'm
> not sure that's as intuitive and obvious as "noinline".  I don't
> like the perhaps immediately obvious "always_call", because I
> think the calls should be deleted if the call-site is dead, just
> not for reasons found out from analysis of the called function,
> and the name suggests otherwise (alternatively, an implementation
> to stop dead-code elimination would be troublesome and useless. :)
>
> Or, just make "noinline" functions that are also "extern" stay
> extern and called.
>
> (Yeah, new attributes "impure" and/or "nonconst" would solve
> this, but only for IPA and there's already the existing option
> and asm I mentioned.  And if you say different files/compilation
> units, I say LTO.)

You can apart from the other suggestions also mark the function weak
which will prevent both inlining and pure/const analysis.

Richard.

> brgds, H-P
>

Re: How to stop gcc from not calling noinline functions

[Hans-Peter Nilsson]

> Date: Sat, 12 Jan 2008 11:16:23 +0100
> From: Paolo Bonzini <bonzini@gnu.org>

> > (Yeah, new attributes "impure" and/or "nonconst" would solve
> > this, but only for IPA and there's already the existing option
> > and asm I mentioned.  And if you say different files/compilation
> > units, I say LTO.)
> 
> I think the asm is your best bet.

I prefer not to bet at all. ;)

Let's make this:
 asm ("");
(asms without input and output operands are volatile, and we're
also leaving the text empty) in the called function the
promised, documented way to stop interfunction analysis (like
currently const/pure) making calls "as it used to be".  Not all
targets support "weak", and overloading a standard qualifier
like "volatile" or "extern" seems on second thought too brittle.

brgds, H-P

RE: How to stop gcc from not calling noinline functions

[Dave Korn]

On 14 January 2008 11:03, Hans-Peter Nilsson wrote:

>> Date: Sat, 12 Jan 2008 11:16:23 +0100
>> From: Paolo Bonzini <bonzini@gnu.org>
> 
>>> (Yeah, new attributes "impure" and/or "nonconst" would solve
>>> this, but only for IPA and there's already the existing option
>>> and asm I mentioned.  And if you say different files/compilation
>>> units, I say LTO.)
>> 
>> I think the asm is your best bet.
> 
> I prefer not to bet at all. ;)
> 
> Let's make this:
>  asm ("");
> (asms without input and output operands are volatile, and we're
> also leaving the text empty) in the called function the
> promised, documented way to stop interfunction analysis (like
> currently const/pure) making calls "as it used to be".  Not all
> targets support "weak", and overloading a standard qualifier
> like "volatile" or "extern" seems on second thought too brittle.
> 
> brgds, H-P

  If you wanted to stick to standard C, you could surely force it with a call
through function pointer, perhaps?  (You might need to make it volatile to
fool IPA.)


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: How to stop gcc from not calling noinline functions

[Jan Hubicka]

> On 14 January 2008 11:03, Hans-Peter Nilsson wrote:
> 
> >> Date: Sat, 12 Jan 2008 11:16:23 +0100
> >> From: Paolo Bonzini <bonzini@gnu.org>
> > 
> >>> (Yeah, new attributes "impure" and/or "nonconst" would solve
> >>> this, but only for IPA and there's already the existing option
> >>> and asm I mentioned.  And if you say different files/compilation
> >>> units, I say LTO.)
> >> 
> >> I think the asm is your best bet.
> > 
> > I prefer not to bet at all. ;)
> > 
> > Let's make this:
> >  asm ("");
> > (asms without input and output operands are volatile, and we're
> > also leaving the text empty) in the called function the
> > promised, documented way to stop interfunction analysis (like
> > currently const/pure) making calls "as it used to be".  Not all
> > targets support "weak", and overloading a standard qualifier
> > like "volatile" or "extern" seems on second thought too brittle.
> > 
> > brgds, H-P
> 
>   If you wanted to stick to standard C, you could surely force it with a call
> through function pointer, perhaps?  (You might need to make it volatile to
> fool IPA.)

My preferred variant would be probably simple increment of global
variable...

Honza
> 
> 
>     cheers,
>       DaveK
> -- 
> Can't think of a witty .sigline today....

Re: How to stop gcc from not calling noinline functions

[Hans-Peter Nilsson]

> From: "Dave Korn" <dave.korn@artimi.com>
> Date: Mon, 14 Jan 2008 11:26:33 -0000

>   If you wanted to stick to standard C, you could surely force it with a call
> through function pointer, perhaps?  (You might need to make it volatile to
> fool IPA.)

No.  No tricks in the calling function.  To reiterate my main
use: test-cases.  Changing from a direct function call in the
original code to indirect is too much a difference, not to say a
(pointer to) volatile.

brgds, H-P

RE: How to stop gcc from not calling noinline functions

[Dave Korn]

On 14 January 2008 11:43, Hans-Peter Nilsson wrote:

>> From: "Dave Korn" <dave.korn@artimi.com>
>> Date: Mon, 14 Jan 2008 11:26:33 -0000
> 
>>   If you wanted to stick to standard C, you could surely force it with a
>> call through function pointer, perhaps?  (You might need to make it
>> volatile to fool IPA.)
> 
> No.  No tricks in the calling function.  To reiterate my main
> use: test-cases.  Changing from a direct function call in the
> original code to indirect is too much a difference, not to say a
> (pointer to) volatile.

  Oops, yes it is, I just re-read your original post; it's the caller, and the
call itself you care about, not what's in the (inlined-or-not) callee.
Apologies.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: How to stop gcc from not calling noinline functions

[Mark Mitchell]

Richard Guenther wrote:

> You can apart from the other suggestions also mark the function weak
> which will prevent both inlining and pure/const analysis.

How about just writing to a volatile variable from within the callee?

void f() __attribute__((noinline)) {
   volatile int i;
   i = 3;
}

void g() {
   f();
}

A valid GNU C compiler cannot eliminate the call to "f", as long as the 
call itself is reachable.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: How to stop gcc from not calling noinline functions

[Hans-Peter Nilsson]

> Date: Wed, 06 Feb 2008 15:59:21 -0800
> From: Mark Mitchell <mark@codesourcery.com>

> Richard Guenther wrote:
> 
> > You can apart from the other suggestions also mark the function weak
> > which will prevent both inlining and pure/const analysis.
> 
> How about just writing to a volatile variable from within the callee?

Can't we just please stick with the asm as agreed on (which
already *is* volatile and besides is recognizable as magical,
should the need arise), and have the documentation patch
approved by a >= middle-end maintainer?  ;)

brgds, H-P