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

[David Blaikie via llvm-dev]

On Thu, Jun 22, 2017 at 11:11 AM Davide Italiano <davide at freebsd.org> wrote:

> 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?
>

There were bugs. I fixed them. :) (specifically it was a combination of
FunctionAttrs proving readnone on an optnone function - fixed. And the
alwaysinliner killing trivially dead calls (so any function call with
readnone, even without alwaysinline, could be 'inlined' (removed) by the
alwaysinliner) - also fixed)


>
> --
> Davide
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170622/f04e78e2/attachment.html>