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

[Daniel Berlin via llvm-dev]

>
>
> I think the fundamental thing you're missing is that benchmarks are an
> exercise in if/then:
>

I don't believe i'm actually missing anything.


>
> *If* a user exercises this API, *then* how well would it perform?


In this case, he exercised the API, and the compiler optimized it away.
If he wants to test whether the API, exercised in some other way, will be
optimized, he should test that.

Your argument that this can't be tested is *almost always* false.  It's
true sometimes, but that's *actually pretty rare*.


> Of course, in the case of a user, the data could come from anywhere, and
> go anywhere - the terminal, a network socket, whatever.
>
> However, in a benchmark, all the data comes from (and goes) to places the
> compiler and see.
>

This is not necessarily true, but as I said, the way around this is to use
volatile.


>
> Thus, it's necessary to make the compiler _pretend_ the data came from
> and goes to a "black box", in order for the benchmarks to even *remotely*
> resemble what they're meant to test.
>


> This is actually distinct from #1, #2, _and_ #3 above - quite simply,
> what is needed is a way to simulate a "real usage" scenario without
> actually contacting the external world.
>
>
No. It is not distinct in any way, and you haven't shown why it is.
It is exactly  "i want this operation to happen exactly X times despite
whether the compiler thinks it is necessary or can be removed"

That is volatile.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151109/016f3924/attachment.html>