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

Philip Reames via llvm-dev llvm-dev at lists.llvm.org
Mon Nov 9 10:20:41 PST 2015


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>


More information about the llvm-dev mailing list