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

[Matt Arsenault via llvm-dev]

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

-Matt