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

[Richard Diamond via llvm-dev]

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>