Joerg Sonnenberger via llvm-dev
2017-Jun-22 14:35 UTC
[llvm-dev] How to prevent optimizing away a call + its arguments
On Wed, Jun 21, 2017 at 05:25:04PM -0700, Mehdi AMINI via llvm-dev wrote:> Hi Kuba, > > Try: > > __attribute__(optnone) > > See > https://clang.llvm.org/docs/AttributeReference.html#optnone-clang-optnoneActually, it should be enough to use: __attribute__((noinline)) void please_do_not_optimize_me_away(int arg1, void *arg2) { asm volatile("":::"memory"); } Creating a real barrier is important. Joerg
David Blaikie via llvm-dev
2017-Jun-22 17:35 UTC
[llvm-dev] How to prevent optimizing away a call + its arguments
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? On Thu, Jun 22, 2017 at 7:35 AM Joerg Sonnenberger via llvm-dev < llvm-dev at lists.llvm.org> wrote:> On Wed, Jun 21, 2017 at 05:25:04PM -0700, Mehdi AMINI via llvm-dev wrote: > > Hi Kuba, > > > > Try: > > > > __attribute__(optnone) > > > > See > > > https://clang.llvm.org/docs/AttributeReference.html#optnone-clang-optnone > > Actually, it should be enough to use: > > __attribute__((noinline)) > void please_do_not_optimize_me_away(int arg1, void *arg2) { > asm volatile("":::"memory"); > } > > Creating a real barrier is important. > > 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/94dd9fc6/attachment.html>
David Majnemer via llvm-dev
2017-Jun-22 17:40 UTC
[llvm-dev] How to prevent optimizing away a call + its arguments
noinline should, and does, not mean "do not do IPO"; we will still do IPCP. The easiest way to defeat IPO is to use __attribute__((weak)) as it makes isDefinitionExact false: https://godbolt.org/g/VVBcgF On Thu, Jun 22, 2017 at 10:35 AM, David Blaikie via llvm-dev < llvm-dev at lists.llvm.org> 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? > > > On Thu, Jun 22, 2017 at 7:35 AM Joerg Sonnenberger via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> On Wed, Jun 21, 2017 at 05:25:04PM -0700, Mehdi AMINI via llvm-dev wrote: >> > Hi Kuba, >> > >> > Try: >> > >> > __attribute__(optnone) >> > >> > See >> > https://clang.llvm.org/docs/AttributeReference.html# >> optnone-clang-optnone >> >> Actually, it should be enough to use: >> >> __attribute__((noinline)) >> void please_do_not_optimize_me_away(int arg1, void *arg2) { >> asm volatile("":::"memory"); >> } >> >> Creating a real barrier is important. >> >> Joerg >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > > _______________________________________________ > 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/cc54ed6d/attachment.html>
Davide Italiano via llvm-dev
2017-Jun-22 17:41 UTC
[llvm-dev] How to prevent optimizing away a call + its arguments
On Jun 22, 2017 10:36 AM, "David Blaikie via llvm-dev" < llvm-dev at lists.llvm.org> 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? IMHO, No. The only semantic of noinline is that the inliner(s) pass shouldn't do anything with that function. Inhibiting IPO seems like could be a valid usecase but that would need a different attribute (e.g. noipo). -- Davide On Thu, Jun 22, 2017 at 7:35 AM Joerg Sonnenberger via llvm-dev < llvm-dev at lists.llvm.org> wrote:> On Wed, Jun 21, 2017 at 05:25:04PM -0700, Mehdi AMINI via llvm-dev wrote: > > Hi Kuba, > > > > Try: > > > > __attribute__(optnone) > > > > See > > https://clang.llvm.org/docs/AttributeReference.html# > optnone-clang-optnone > > Actually, it should be enough to use: > > __attribute__((noinline)) > void please_do_not_optimize_me_away(int arg1, void *arg2) { > asm volatile("":::"memory"); > } > > Creating a real barrier is important. > > Joerg > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >_______________________________________________ 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/804a8b08/attachment.html>
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
Kuba Mracek via llvm-dev
2017-Jun-22 18:31 UTC
[llvm-dev] How to prevent optimizing away a call + its arguments
> Actually, it should be enough to use: > > __attribute__((noinline)) > void please_do_not_optimize_me_away(int arg1, void *arg2) { > asm volatile("":::"memory"); > } > > Creating a real barrier is important.This doesn't work – the call still gets turned into please_do_not_optimize_me_away(undef, undef).> __attribute__((optnone))optnone works, but I'm actually surprised by this. I would expect that it would only affect the generated code of that function... Is it guaranteed to work? Or is my safest bet still to use: __attribute__((noinline)) void please_do_not_optimize_me_away(int arg1, void *arg2) { asm volatile("" :: "r" (arg1), "r" (arg2) : "memory"); } (The other benefit compared to optnone is that this will actually generate a nice empty function. Using optnone generates code that stores the arguments to the stack.) Kuba
David Blaikie via llvm-dev
2017-Jun-22 18:51 UTC
[llvm-dev] How to prevent optimizing away a call + its arguments
On Thu, Jun 22, 2017 at 11:40 AM Kuba Mracek via llvm-dev < llvm-dev at lists.llvm.org> wrote:> > Actually, it should be enough to use: > > > > __attribute__((noinline)) > > void please_do_not_optimize_me_away(int arg1, void *arg2) { > > asm volatile("":::"memory"); > > } > > > > Creating a real barrier is important. > > This doesn't work – the call still gets turned into > please_do_not_optimize_me_away(undef, undef). > > > __attribute__((optnone)) > > optnone works, but I'm actually surprised by this. I would expect that it > would only affect the generated code of that function... > > Is it guaranteed to work?Modulo bugs, yes - optnone should have the same behavior as if you put the function definition in another file and compiled that file with -O0.> Or is my safest bet still to use: > > __attribute__((noinline)) > void please_do_not_optimize_me_away(int arg1, void *arg2) { > asm volatile("" :: "r" (arg1), "r" (arg2) : "memory"); > } > > (The other benefit compared to optnone is that this will actually generate > a nice empty function. Using optnone generates code that stores the > arguments to the stack.) > > Kuba > > _______________________________________________ > 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/7938f66f/attachment.html>
Matthias Braun via llvm-dev
2017-Jun-22 18:55 UTC
[llvm-dev] How to prevent optimizing away a call + its arguments
It looks like what you are trying to do here is define a weak function. Marking the function as weak should have the desired effect, though last time I looked apple paltforms only had limited support for weak functions... - Matthias> On Jun 22, 2017, at 11:31 AM, Kuba Mracek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > >> Actually, it should be enough to use: >> >> __attribute__((noinline)) >> void please_do_not_optimize_me_away(int arg1, void *arg2) { >> asm volatile("":::"memory"); >> } >> >> Creating a real barrier is important. > > This doesn't work – the call still gets turned into please_do_not_optimize_me_away(undef, undef). > >> __attribute__((optnone)) > > optnone works, but I'm actually surprised by this. I would expect that it would only affect the generated code of that function... > > Is it guaranteed to work? Or is my safest bet still to use: > > __attribute__((noinline)) > void please_do_not_optimize_me_away(int arg1, void *arg2) { > asm volatile("" :: "r" (arg1), "r" (arg2) : "memory"); > } > > (The other benefit compared to optnone is that this will actually generate a nice empty function. Using optnone generates code that stores the arguments to the stack.) > > Kuba > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Joerg Sonnenberger via llvm-dev
2017-Jun-22 19:10 UTC
[llvm-dev] How to prevent optimizing away a call + its arguments
On Thu, Jun 22, 2017 at 11:31:41AM -0700, Kuba Mracek wrote:> > Actually, it should be enough to use: > > > > __attribute__((noinline)) > > void please_do_not_optimize_me_away(int arg1, void *arg2) { > > asm volatile("":::"memory"); > > } > > > > Creating a real barrier is important. > > This doesn't work – the call still gets turned into please_do_not_optimize_me_away(undef, undef).If you also want it to preserve the arguments (that wasn't clear to me), just add them as arguments to the asm statement? Joerg