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

[David Chisnall via llvm-dev]

On 2 Sep 2015, at 02:54, Joseph Tremoulet via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Reading further, I see both that addrspacecast "can be a no-op cast or a complex value modification"[2] and that bitcast "may only be [used on pointers] with the same address space"[4].
> 
> So I'm getting the impression that it's ok to have a model with semantically meaningful aliasing between address spaces, but also that anywhere we want to reference a local's address with an addrspace(1) pointer (which is everywhere our source language takes its address), as things stand now we need either to use an addrspace cast which will be assumed to possibly have side-effects, or to round-trip through ptrtoint/inttoptr which I presume will obscure the aliasing information.  It certainly gives us a correct place to start from, but (unless I'm misunderstanding and the "complex value modification" type of addrspacecast isn't assumed to have side-effects) I wouldn't be surprised if we come back to this wanting a way to represent a cast across address spaces that's as transparent as a bitcast.

To give a bit of background on that:

The use case for introducing AS casts as distinct from bitcasts (and not going via inttoptr / ptrtoint) is architectures that have different pointer representations.  For example, some microcontrollers have a 16-bit PC and 32-bit address registers, allowing code pointers to be smaller than data pointers.  Some GPUs (used to?) use different sized pointers for the various different places in the memory hierarchy.  In our architecture, this is even more complicated, because we support two different pointer representations:

- 256-bit (or 128-bit, on newer revisions) memory capabilities, that both identify and grant access to a region of memory and have unforgeability guaranteed by the hardware.  In LLVM, we represent these as pointers with AS 0.

- 64-bit legacy-compabible pointers that are implicitly relative to a global capability (and so are only dereferenceable within a restricted range of the process’ virtual address space).  In LLVM, we represent these as pointers with AS 0.

For us, an AS cast between AS 0 and AS 200 will succeed if and only if the address is within the current range of the global capability.  Any address in AS 0 may alias any address in AS 200 (except in some trivial cases, it’s impossible to determine statically that they don’t), but one value is an integer interpreted as an address, whereas the other is a fat pointer with bounds and permissions enforced in hardware.

David