[llvm-dev] RFC: alloca -- specify address space for allocation

[Chandler Carruth via llvm-dev]

On Tue, Sep 8, 2015 at 8:05 AM Joseph Tremoulet via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Thanks, having that context is very helpful.
>
> I actually think our use case is somewhat similar in spirit, as one of the
> key points of our system is treating object identity as
> unforgeable/unforged (guaranteed by type rules in verified safe code,
> assumed but unverified in trusted unsafe code).
>
> So the main question left for me is how much of a hinderance the pervasive
> addrspacecasts we may have will be for optimization.  Things like:
>  - Can two addrspace casts be reordered past each other?
>

Yes.


>  - Can an addrspace cast be reordered across memory dereferences?
>

Yes.


>  - Can two addrspacecasts with the same input value be CSE'd?
>

Yes.


>  - Is an address presumed to be escaped when it is addrspacecasted?
>

No.


>  - If we load from a pointer `%p` and from a pointer `%q` which is an
> addrspacecast of `%p`, will those loads be seen as redundant?
>

According to the spec, yes. I'm not saying we implement this, but the spec
is quite clear (to my surprise): "Note that if the address space conversion
is legal then both result and operand refer to the same memory location."


>    - Can a store to `%p` feeding a load from `%q`, or vice-versa, be
> replaced with an SSA value?
>

As above, the spec is quite clear: yes.

 - Can an addrspacecast be hoisted to where it will be speculatively
> executed?
>

The spec is actually unclear about this, and that is true for almost every
such instruction. This is one of the most egregious bugs in our spec (see
below) but you can find the current answer the optimizer believes by
consulting the implementation of isSafeToSpeculativelyExecute, and it seems
to return "true" for addrspacecast.


None of this is to say that these things couldn't be changed, or that the
optimizer even currently leverages them, but that is what the spec
currently says about addrspacecast.



>
> Popping up a level: when I have these sorts of questions about an opcode,
> and I don't see them spelled out in its entry in the LangRef, where should
> I look?  Is there some central place describing such properties, or would I
> just need to read/test the relevant optimizations?
>

It is useful to think of the LangRef as the *spec* for the IR. As a
consequence, the LangRef *is* the only source of truth for these things.
The only thing that may be more accurate is the implementation, but that is
always a bug, it just may be a bug in the LangRef. We do have lots of bugs
though, for example we don't specify whether instructions are speculatable
very clearly. We also don't specify some other properties. In this case
though, most of your questions are there.

One way in which the LangRef is perhaps odd is that everything is generally
assumed to be a pure operation on its arguments unless specified as
something else. That may have led to the confusion, and why I see simple
answers to the above questions.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150908/989cad60/attachment.html>