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

One thing that volatile doesn't do is escape results that have been written
to memory.

The proposed blackbox intrinsic is modeled as reading and writing any
pointed to memory, which is useful.

I also think blackbox will be a lot easier for people to use than empty
volatile inline asm and volatile loads and stores. That alone seems worth
something. :)

On Mon, Nov 9, 2015 at 6:04 PM, Daniel Berlin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
>> 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.
>
>
> _______________________________________________
> 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/20151109/62e1a0f5/attachment.html>

On Mon, Nov 9, 2015 at 7:46 PM, Reid Kleckner <rnk at google.com> wrote:
> One thing that volatile doesn't do is escape results that have been
> written to memory.
>
>
Honestly, i'd probably rather see attributes or something than this
intrinsic.

That said ....


> The proposed blackbox intrinsic is modeled as reading and writing any
> pointed to memory, which is useful.
>
>
The proposed intrinsic does not have a really well defined exact set of
semantics.
If it did, and those semantics made sense, i think you'd see a lot less
pushback.

> I also think blackbox will be a lot easier for people to use than empty
> volatile inline asm and volatile loads and stores. That alone seems worth
> something. :)
>
>
Yes, but at the same time, it seems very "Do What I Mean".

Those kinds of intrinsics rarely turn out to be sane and maintainable ;-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151109/ae27f7d6/attachment.html>

I think the idea is to model the intrinsic as a normal external function
call:
- Can read/write escaped memory
- Escapes pointer args
- Functionattrs cannot infer anything about it
- Returns a pointer which may alias any escaped data

It's obvious how this works at the IR level, but I'm not sure what would
happen in the backend. If you compile the intrinsic to nothing but a
virtual register copy, MI optimizations will kick in. You might get away
with compiling it to a volatile store/load, and hope that the time for
high-level memory optimizations like GVN is over.

On Mon, Nov 9, 2015 at 8:58 PM, Daniel Berlin <dberlin at dberlin.org>
wrote:
>
>
> On Mon, Nov 9, 2015 at 7:46 PM, Reid Kleckner <rnk at google.com>
wrote:
>
>> One thing that volatile doesn't do is escape results that have been
>> written to memory.
>>
>>
> Honestly, i'd probably rather see attributes or something than this
> intrinsic.
>
> That said ....
>
>
>
>> The proposed blackbox intrinsic is modeled as reading and writing any
>> pointed to memory, which is useful.
>>
>>
> The proposed intrinsic does not have a really well defined exact set of
> semantics.
> If it did, and those semantics made sense, i think you'd see a lot less
> pushback.
>
>
>> I also think blackbox will be a lot easier for people to use than empty
>> volatile inline asm and volatile loads and stores. That alone seems
worth
>> something. :)
>>
>>
> Yes, but at the same time, it seems very "Do What I Mean".
>
> Those kinds of intrinsics rarely turn out to be sane and maintainable ;-)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151111/a25b3030/attachment.html>