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

[Philip Reames via llvm-dev]

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>