Joerg Sonnenberger via llvm-dev
2017-Jun-22 17:45 UTC
[llvm-dev] How to prevent optimizing away a call + its arguments
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) and making sure that the debugger can actually do something at this point (noinline should not have to allow that). Joerg
David Blaikie via llvm-dev
2017-Jun-22 18:03 UTC
[llvm-dev] How to prevent optimizing away a call + its arguments
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>
Davide Italiano via llvm-dev
2017-Jun-22 18:10 UTC
[llvm-dev] How to prevent optimizing away a call + its arguments
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
Joerg Sonnenberger via llvm-dev
2017-Jun-22 19:06 UTC
[llvm-dev] How to prevent optimizing away a call + its arguments
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