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

[David Blaikie via llvm-dev]

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.


> and
> making sure that the debugger can actually do something at this point
> (noinline should not have to allow that).
>
> Joerg
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170622/acdfc691/attachment.html>