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

[Daniel Berlin via llvm-dev]

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>