Philip Reames via llvm-dev
2015-Nov-03 23:09 UTC
[llvm-dev] [RFC] A new intrinsic, `llvm.blackbox`, to explicitly prevent constprop, die, etc optimizations
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>
Björn Steinbrink via llvm-dev
2015-Nov-04 00:04 UTC
[llvm-dev] [RFC] A new intrinsic, `llvm.blackbox`, to explicitly prevent constprop, die, etc optimizations
2015-11-04 0:09 GMT+01:00 Philip Reames via llvm-dev <llvm-dev at lists.llvm.org>:> 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?I wonder the same. Richard, maybe we just need something more specific in Rust? Like something that only clobbers memory? Or just the variable? Seems like we could do with specialized "block_box` functions. AIUI our `black_box` got extended to prevent more optimizations as it became obvious that the compiler could still "defeat" it. Maybe we need to take a step back and say "ok, we'll have to think a bit harder and decide how hard we'll be on the optimizer"? Is there anything that speaks against that and requires an intrinsic? Cheers, Björn
Richard Diamond via llvm-dev
2015-Nov-06 16:36 UTC
[llvm-dev] [RFC] A new intrinsic, `llvm.blackbox`, to explicitly prevent constprop, die, etc optimizations
On Tue, Nov 3, 2015 at 5:09 PM, Philip Reames <listmail at philipreames.com> wrote:> 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 >This intrinsic is designed to provide exactly this (assuming `__builtin_blackbox` is also added to clang): int a = __builtin_blackbox(5);> int b = 7; > void add_two_globals() > sink(a+b) >And: __builtin_blackbox(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? >Because Rust's `test::black_box` is generic, it can't be an external function. Also, code using this will actually be executed, so it's also not good enough to leave it undefined. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151106/0bef8754/attachment.html>
Philip Reames via llvm-dev
2015-Nov-09 18:20 UTC
[llvm-dev] [RFC] A new intrinsic, `llvm.blackbox`, to explicitly prevent constprop, die, etc optimizations
On 11/06/2015 08:36 AM, Richard Diamond wrote:> > > On Tue, Nov 3, 2015 at 5:09 PM, Philip Reames > <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote: > > 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 > > > This intrinsic is designed to provide exactly this (assuming > `__builtin_blackbox` is also added to clang): > > int a = __builtin_blackbox(5); > > int b = 7; > void add_two_globals() > sink(a+b) > > > And: > > __builtin_blackbox(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? > > > Because Rust's `test::black_box` is generic, it can't be an external > function. Also, code using this will actually be executed, so it's > also not good enough to leave it undefined.This statement doesn't make sense to me. What does generic have to do with being external? And why can't an external function be defined? Philip -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151109/043f7055/attachment.html>