[LLVMdev] Address space extension

[David Chisnall]

On 8 Aug 2013, at 17:51, Pete Cooper <peter_cooper at apple.com> wrote:

> In the example David gave with address spaces 0 and 256. Clearly there isn't a single HW instruction which can use the value of the pointer to do the right thing at run time here. You really must generate different code. Therefore in the hierarchy 0 and 256 would be defined to not overlap and the cast would be invalid.

Note that, in this case, values in address space 0 can alias ones in address space 256.  A cast from address space 256 to 0 can be implemented by a single instruction, because it's just translating the segment-relative address to a linear address.  The converse may be possible, if the linear address happens to reside within the segment.  Probably the correct thing to do would be subtract the segment base from the linear address and then have a pointer that would trap on use if it is invalid.  

We have a similar issue where we are using an address space to represent fat pointers.  The relevant problem that we have is that we have 64-bit and 256-bit pointers in our architecture, and it's quite difficult to persuade LLVM that it shouldn't insert bitcasts between them (and so we have a fork where we'd like to have an out-of-tree back end).  In our case, we also have issues preventing GEPs from being canonicalised to use 256-bit offsets, even though only 64 bits of the base in the fat pointer are the base address, and we have no i256 type.  

We've hacked up SelectionDAG to have an iFATPTR type, but ideally we'd have iPTR16, iPTR32 and so on up to iPTR256 (or even iPTR512 for architectures even more weird than ours) and an explicit PTRCAST node to convert between them (currently we have INTTOPTR and PTRTOINT nodes in our SelectionDAG and special pattern matching.  This is quite ugly, but it allowed us to get away without changing the bitcode format.  It's not a good solution though).  We'd also like something in DataLayout or similar to indicate whether a pointer is an integer or a fat pointer.

A related issue is that TableGen really really likes the idea that the is-a-pointer constraint allows it to determine the type.  This means that supporting atomic operations on architectures that have multiple types of pointer in SelectionDAG is very hard.

David