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

[Joerg Sonnenberger via llvm-dev]

On Thu, Jun 22, 2017 at 06:03:39PM +0000, David Blaikie 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.

I'm not saying it does that. But I am saying that is why someone might
want to use it. That's why I gave the example with the memory clobber --
that is known to work for both GCC and Clang and fits here in the sense
that (1) it can't be duplicated (2) it contains a side effect. Now
whether this is the semantic we want to have for noinline is a different
question.

Joerg