llvm dev - Nov 2015 - [RFC] A new intrinsic, `llvm.blackbox`, to explicitly prevent constprop, die, etc optimizations

On Mon, Nov 2, 2015 at 7:19 PM, Sanjoy Das <sanjoy at
playingwithpointers.com>
wrote:
> Why does this need to be an intrinsic (as opposed to generic "unknown
> function" to llvm)?
>
> Secondly, have you looked into a volatile store / load to an alloca? That
> should work with PNaCl and WebAssembly.
>
> E.g.
>
> define i32 @blackbox(i32 %arg) {
>  entry:
>   %p = alloca i32
>   store volatile i32 10, i32* %p  ;; or store %arg
>   %v = load volatile i32, i32* %p
>   ret i32 %v
> }

That volatility would have a negative performance impact.

Richard Diamond
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151102/c969d51d/attachment-0001.html>

I'm very unclear and why you think a generic black box intrinsic will have
any different performance impact ;-)


I'm also unclear on what the goal with this intrinsic is.
I understand the symptoms you are trying to solve - what exactly is the
disease.

IE you say "

I'd like to propose a new intrinsic for use in preventing optimizations
from deleting IR due to constant propagation, dead code elimination, etc."

But why are you trying to achieve this goal?
Benchmarks that can be const prop'd/etc away are often meaningless.  Past
that, if you want to ensure a particular optimization does a particular
thing on a benchmark, ISTM it would be better to generate the IR, run opt
(or build your own pass-by-pass harness), and then run "the passes you want
on it" instead of "trying to stop certain passes from doing things to
it".


On Mon, Nov 2, 2015 at 5:23 PM, Richard Diamond via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
>
> On Mon, Nov 2, 2015 at 7:19 PM, Sanjoy Das <sanjoy at
playingwithpointers.com
> > wrote:
>
>> Why does this need to be an intrinsic (as opposed to generic
"unknown
>> function" to llvm)?
>>
>> Secondly, have you looked into a volatile store / load to an alloca?
That
>> should work with PNaCl and WebAssembly.
>>
>> E.g.
>>
>> define i32 @blackbox(i32 %arg) {
>>  entry:
>>   %p = alloca i32
>>   store volatile i32 10, i32* %p  ;; or store %arg
>>   %v = load volatile i32, i32* %p
>>   ret i32 %v
>> }
>
>
> That volatility would have a negative performance impact.
>
> Richard Diamond
>
> _______________________________________________
> 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/20151102/195ebc7a/attachment.html>

On Mon, Nov 2, 2015 at 9:16 PM, Daniel Berlin <dberlin at dberlin.org>
wrote:
> I'm very unclear and why you think a generic black box intrinsic will
have
> any different performance impact ;-)
>
>
> I'm also unclear on what the goal with this intrinsic is.
> I understand the symptoms you are trying to solve - what exactly is the
> disease.
>
> IE you say "
>
> I'd like to propose a new intrinsic for use in preventing optimizations
> from deleting IR due to constant propagation, dead code elimination,
etc."
>
> But why are you trying to achieve this goal?
>
It's a cleaner design than current solutions (as far as I'm aware).

> Benchmarks that can be const prop'd/etc away are often meaningless.
>
A benchmark that's completely removed is even more meaningless, and the
developer may not even know it's happening. I'm not saying this
intrinsic
will make all benchmarks meaningful (and I can't), I'm saying that it
would
be useful in Rust in ensuring that tests/benches aren't invalidated simply
because a computation wasn't performed.

Past that, if you want to ensure a particular optimization does
a
> particular thing on a benchmark, ISTM it would be better to generate the
> IR, run opt (or build your own pass-by-pass harness), and then run
"the
> passes you want on it" instead of "trying to stop certain passes
from doing
> things to it".
>
True, but why would you want to force that speed bump onto other
developers? I'd argue that's more hacky than the inline asm.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151103/ce6d1a5c/attachment.html>

The common use case I've seen for a black box like construct is when 
writing microbenchmarks.  In particular, you're generally looking for a 
way to "sink" the result of a computation without having that sink 
outweigh the cost of the thing you're trying to measure.

Common alternate approaches are to use a volatile store (so that it 
can't be eliminated or sunk out of loops) or a call to an external 
function with a cheap calling convention.

As an example:
int a = 5; // initialization is not visible to compiler
int b = 7;
void add_two_globals()
   sink(a+b)
}

If what I'm look into is the code generation around addition, this is a 
very useful way of testing the entire compiler - frontend, middle end, 
and backend.

I'll note that we use such a framework extensively.

What I'm not clear on is why this needs to be an intrinsic.  Why does a 
call to an external function or a volatile store not suffice?

Philip



On 11/02/2015 07:16 PM, Daniel Berlin via llvm-dev
wrote:
> I'm very unclear and why you think a generic black box intrinsic will 
> have any different performance impact ;-)
>
>
> I'm also unclear on what the goal with this intrinsic is.
> I understand the symptoms you are trying to solve - what exactly is 
> the disease.
>
> IE you say "
>
> I'd like to propose a new intrinsic for use in preventing 
> optimizations from deleting IR due to constant propagation, dead code 
> elimination, etc."
>
> But why are you trying to achieve this goal?
> Benchmarks that can be const prop'd/etc away are often meaningless.  
> Past that, if you want to ensure a particular optimization does a 
> particular thing on a benchmark, ISTM it would be better to generate 
> the IR, run opt (or build your own pass-by-pass harness), and then run 
> "the passes you want on it" instead of "trying to stop
certain passes
> from doing things to it".
>
>
> On Mon, Nov 2, 2015 at 5:23 PM, Richard Diamond via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
>
>
>
>     On Mon, Nov 2, 2015 at 7:19 PM, Sanjoy Das
>     <sanjoy at playingwithpointers.com
>     <mailto:sanjoy at playingwithpointers.com>> wrote:
>
>         Why does this need to be an intrinsic (as opposed to generic
>         "unknown function" to llvm)?
>
>         Secondly, have you looked into a volatile store / load to an
>         alloca? That should work with PNaCl and WebAssembly.
>
>         E.g.
>
>         define i32 @blackbox(i32 %arg) {
>          entry:
>           %p = alloca i32
>           store volatile i32 10, i32* %p  ;; or store %arg
>           %v = load volatile i32, i32* %p
>           ret i32 %v
>         }
>
>
>     That volatility would have a negative performance impact.
>
>     Richard Diamond
>
>     _______________________________________________
>     LLVM Developers mailing list
>     llvm-dev at lists.llvm.org <mailto: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/20151103/cb9903c1/attachment.html>