[llvm-dev] How to prevent optimizing away a call + its arguments

[Davide Italiano via llvm-dev]

On Thu, Jun 22, 2017 at 11:03 AM, David Blaikie via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
>
> On Thu, Jun 22, 2017 at 10:45 AM Joerg Sonnenberger via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>>
>> On Thu, Jun 22, 2017 at 05:35:51PM +0000, David Blaikie wrote:
>> > optnone should work, but really noinline should probably (Chandler: Can
>> > you
>> > confirm: is it reasonable to model noinline as "no interprocedural
>> > analysis
>> > across this function boundary" (so FunctionAttrs should do the same
>> > thing
>> > for noinline as it does for optnone, for example? ie: not derive any new
>> > attributes) - allowing the function to be optimized internally (unlike
>> > optnone) but not allowing interprocedural analysis inside the function
>> > to
>> > be used in callers (unlike optnone)) work as well?
>>
>> I don't think it is reasonable to expect "noinline" to mean "must not do
>> IPA". There are different reasons for using "noinline": ensuring a stack
>> frame, forcing outlining of "cold" code etc. Many of those reasons are
>> perfectly fine to still allow IPA. Debug hooks fall into two categories:
>> making sure that the call happens (noinline should allow that)
>
>
> noinline (& in fact, even optnone) doesn't make sure the call happens -
> various forms of IPA can cause a call to go away without actually inlining.
>
> (simplest example, that even the inliner got wrong (& I fixed recently,
> which is why any of this comes to mind/I have any context on it) - the
> inliner removed a call to an optnone+readnone function without consulting
> the inliner heuristic (this was in the alwaysinliner) because it assumed the
> operation was so cheap no inliner heuristic would ever disagree, basically
> ;) )
>
> But some other optimization could/would still remove a noinline+readnone
> function because it's a trivially dead instruction (assuming the result
> isn't used). So noinline doesn't preserve the call - because some IPA can,
> in some cases, be as powerful as inlining-ish.
>

I agree, but still I don't think it's `noinline` job to prevent this
from happening. It sounds weird (and probably a POLA violation) having
`noinline` preventing interprocedural constant propagation.
About `optnone`, I'm surprised is not powerful enough to prevent this
from happening, modulo bugs of course. Do you have other examples?

--
Davide