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

> 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

-Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160719/e3864c09/attachment.html>

> 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

-------------- 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/20160720/6e374118/attachment.bin>

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