llvm dev - Jun 2017 - 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-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

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>

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>

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>

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

> 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

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>

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

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