[llvm-dev] [RFC] Make Lanai backend non-experimental

Tue Jul 26 01:20:52 PDT 2016

On 26 Jul 2016, at 01:15, Matt Arsenault <Matthew.Arsenault at amd.com> wrote:
> 
> On 07/20/2016 03:40 AM, David Chisnall via llvm-dev wrote:
>>> On 19 Jul 2016, at 21:05, Matt Arsenault <arsenm2 at gmail.com> wrote:
>>> 
>>>> On Jul 19, 2016, at 09:52, David Chisnall via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>>> 
>>>> The IR disruptions for CHERI aren’t that major (the main thing is that we allow alloca’s in different address spaces, but that’s not too difficult to upstream), but it does fail to tick one box that you didn’t list:
>>> We would like this feature upstreamed
>> Do you have an in-tree target that would make use of it?  If so, I’d be happy to start disentangling it from our tree (I think it’s in a fairly self-contained set of changes).  We only support one alloca address space per module currently, because for our use we’re simply changing the address space of the entire stack, rather than individual allocations, would that be enough for you or do you need something more general?
>> 
>> David
>> 
>> 
> 
> Yes, although there are migration difficulties. For AMDGPU, addrspace(0) is forced to be the OpenCL private address space due to the alloca restriction. 0 is a valid pointer in addrspace(0), so we don't want optimizations making the usual assumptions about dereferencability. Ideally the stack addrspace would be part of the DataLayout and we could also specify the nullptr value

It sounds like what we have is most of what you need then.  The alloca address space is in the DataLayout, though the null pointer value currently isn’t.  We currently assume C semantics that a cast of an integer constant expression 0 is guaranteed to be a null pointer, but make no assumptions about what the bit pattern of 0 is (our pointers are not integers, so encoding a null integer value for a pointer in the data layout would not make sense).  We also have some patches to SelectionDAG to make inttoptr and ptrtoint explicit nodes, not simply bitcast equivalents.  You might want to do this and transform ptrtoint into +1 and inttoptr into -1, so that address 0 becomes integer 1 and integer 0 becomes address 0xffffffff (which hopefully isn’t also a valid address for you).  That allows optimisers to all assume C null semantics.

I’ve put pulling these bits out into a patch for you to review on my todo list, though I have a deadline in a couple of weeks and am not sure if I’ll have time to get around to it before then (you are, of course, welcome to pull patches from our tree if it’s more urgent than that).  

David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3719 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160726/4dcbbe31/attachment.bin>