On Jan 12, 2008 7:20 AM, Hans-Peter Nilsson <[EMAIL PROTECTED]> 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
>
