<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Sep 8, 2015 at 8:05 AM Joseph Tremoulet via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks, having that context is very helpful.<br>
<br>
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).<br>
<br>
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:<br>
 - Can two addrspace casts be reordered past each other?<br></blockquote><div><br></div><div>Yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 - Can an addrspace cast be reordered across memory dereferences?<br></blockquote><div><br></div><div>Yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 - Can two addrspacecasts with the same input value be CSE'd?<br></blockquote><div><br></div><div>Yes.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 - Is an address presumed to be escaped when it is addrspacecasted?<br></blockquote><div><br></div><div>No.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 - 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?<br></blockquote><div><br></div><div>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."</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
   - Can a store to `%p` feeding a load from `%q`, or vice-versa, be replaced with an SSA value?<br></blockquote><div><br></div><div>As above, the spec is quite clear: yes.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 - Can an addrspacecast be hoisted to where it will be speculatively executed?<br></blockquote><div><br></div><div>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.</div><div><br></div><div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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?<br></blockquote><div><div><br></div><div>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.</div></div><div><br></div><div>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.</div><div><br></div><div>-Chandler</div></div></div>