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

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>

On Wed, Nov 11, 2015 at 10:32 AM, Reid Kleckner <rnk at google.com> wrote:
> 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
>
> As you point out so nicely, there is already a list of stuff that external
function calls may do, but we may be able to prove things about them anyway
due to attributes, etc.

So it's not just an external function call, it's a super-magic one.

Now, can we handle that?
Sure.

For example,  i can move external function calls if i can prove things
about their dependencies, and the above list is not sufficient to prevent
me from moving (or PRE'ing) most of the blackbox calls that just take
normal non-pointer args.
Is that going to be okay?

(Imagine, for example, LTO modes where i can guarantee i have the entire
program, etc.
You still want blackbox to be magically special in these modes, even though
nothing else is).




> 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/485fdf64/attachment.html>

On Wed, Nov 11, 2015 at 10:41 AM, Daniel Berlin <dberlin at dberlin.org>
wrote:
> On Wed, Nov 11, 2015 at 10:32 AM, Reid Kleckner <rnk at google.com>
wrote:
>
>> 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
>>
>> As you point out so nicely, there is already a list of stuff that
> external function calls may do, but we may be able to prove things about
> them anyway due to attributes, etc.
>
> So it's not just an external function call, it's a super-magic one.
>
Right, an external function, with a definition that the compiler will never
find.

> Now, can we handle that?
> Sure.
>
> For example,  i can move external function calls if i can prove things
> about their dependencies, and the above list is not sufficient to prevent
> me from moving (or PRE'ing) most of the blackbox calls that just take
> normal non-pointer args.
> Is that going to be okay?
>
> (Imagine, for example, LTO modes where i can guarantee i have the entire
> program, etc.
> You still want blackbox to be magically special in these modes, even
> though nothing else is).
>
Sure, the compiler can reorder all the memory accesses to non-escaped
memory as it sees fit across the barrier. That's part of the normal
modelling of external calls.

I don't know how you could CSE it, though. Any call you can't reason
about
can always use inline asm to talk to external devices or issue a write
syscall. I don't know how you could practically deploy a super-duper LTO
mode that doesn't allow that as part of its model.

The following CFG simplification would be legal, as it also fits the normal
model of an external call:
if (cond) y =llvm.blackbox(x)
else y = llvm.blackbox(x)
-->
y = llvm.blackbox(x)

I don't see how this is special. It just provides an overloaded intrinsic
whose definition we promise to never reason about. Other than that it
follows the same familiar rules that function calls do.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151111/392154e8/attachment.html>