<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
</span>In our architecture, address space casts will never trap and are deterministic (unless there is some asm with unmodelled side effects).  However, there are pointers that can be dereferenced in one address space but not another: speculatively performing the load would be a real bug.<br>
<br>
Ideally, this would be a target-specific decision, but having the default be to not propagate the dereferencing information and allowing targets to opt in.<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">
<br>
I've just been debugging a related issue with regard to commutativity of address space casts with respect to other operations.  One of the optimisers is turning an add after an address space cast into an add before the address space cast.  On our architecture, this results in different bounds information being available on the pointer and a run-time crash.  We could represent casts with a target-specific intrinsic, but we'd rather avoid that if possible. This is not fixed by changing isSafeToSpeculativelyExecute to return false for AddrSpaceCast, so I'll need to dig a bit more to understand exactly when and why it happens.<br><span class="HOEnZb"><font color="#888888"><br></font></span></blockquote><div>Like to know what is causing this.</div><div><br></div><div>Thanks</div><div>Junjie </div></div><br></div></div>