[LLVMdev] possible addrspacecast problem

[David Chisnall]

On 16 Mar 2015, at 08:25, Sanjoy Das <sanjoy at playingwithpointers.com> wrote:
> 
> The LangRef says this about addrspacecast: "Note that if the address
> space conversion is legal then both result and operand refer to the
> same memory location.".  This brings forth two related questions:
> 
> 1. what happens if you execute an "invalid" addrspacecast?  Does this
>    axiom make addrspacecast non-hoistable?  From a quick glance at
>    the code, ValueTracking seems to assume that addrspacecasts can be
>    speculatively executed.
> 
> 2. even if two pointers from two different address spaces point to
>    the same "location", can one of them not be dereferenceable while
>    the other is?  In other words, does dereferenceability depend on
>    the addrspace of the pointer given that the "location" is
>    dereferenceable?

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.

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.

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.

I think there's a lot of code that still assumes that address space casts are basically bitcasts.

David