llvm dev - Mar 2017 - [RFC] Allow allocas to produce a non-0 address space pointer

LLVM makes several assumptions about address space 0. However,

alloca is presently constrained to always return this address space.

There's no real way to avoid using alloca, so without this

there is no way to opt out of these assumptions.


The problematic assumptions include:

  *   That the pointer size used for the stack is the same size as the code size
pointer, which is also the maximum sized pointer.
  *   That 0 is an invalid, non-dereferencable pointer value.

These are problems for AMDGPU because alloca is used to implement the private
address space, which uses a 32-bit index as the pointer value. Other pointers
are 64-bit and behave more like LLVM's notion of generic address space. By
changing the address space used for allocas, we can change our generic pointer
type to be LLVM's generic pointer type which does have similar properties.

The proposal here is to add a -A field to the datalayout string which will
specify the address space for allocas. IRBuilder::CreateAlloca and company gain
a DataLayout argument, and some intrinsics that currently don't support
address spaces need to support them.

This has been implemented out of tree before before for CHERI.


This has also been proposed before but for different reasons:
http://lists.llvm.org/pipermail/llvm-dev/2015-August/089706.html


My current proposal is more focused than the previous proposal. Instead of
allowing specifying address spaces on individual allocas, this restricts it to
one chosen address space specified in the datalayout. I think the work to
support different address spaces per-alloca is a strict superset of this
proposal, so if people are interested in that I think that is a separate step
beyond this.


-Matt


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

On 16 Mar 2017, at 17:51, Arsenault, Matthew <Matthew.Arsenault at
amd.com> wrote:
> 
> This has been implemented out of tree before before for CHERI.
> 
> This has also been proposed before but for different reasons:
http://lists.llvm.org/pipermail/llvm-dev/2015-August/089706.html
> 
> My current proposal is more focused than the previous proposal. Instead of
allowing specifying address spaces on individual allocas, this restricts it to
one chosen address space specified in the datalayout. I think the work to
support different address spaces per-alloca is a strict superset of this
proposal, so if people are interested in that I think that is a separate step
beyond this.
This is exactly what we do for CHERI (one address space for all allocas) and the
changes are quite small.  If they’re useful, please feel free to pull them out
from our tree - we’ve just done a merge from upstream, so they should apply
cleanly.

David

On 3/16/2017 10:51 AM, Arsenault, Matthew via llvm-dev
wrote:
>
> LLVM makes several assumptions about address space 0. However,
>
> alloca is presently constrained to always return this address space.
>
> There's no real way to avoid using alloca, so without this
>
> there is no way to opt out of these assumptions.
>
>
> The problematic assumptions include:
>
>   * That the pointer size used for the stack is the same size as the
>     code size pointer, which is also the maximum sized pointer.
>   * That 0 is an invalid, non-dereferencable pointer value.
>
> These are problems for AMDGPU because alloca is used to implement the 
> private address space, which uses a 32-bit index as the pointer value. 
> Other pointers are 64-bit and behave more like LLVM's notion of 
> generic address space. By changing the address space used for allocas, 
> we can change our generic pointer type to be LLVM's generic pointer 
> type which does have similar properties.
>
> The proposal here is to add a -A field to the datalayout string which 
> will specify the address space for allocas. IRBuilder::CreateAlloca 
> and company gain a DataLayout argument, and some intrinsics that 
> currently don't support address spaces need to support them.
>
I think we should also include the address-space of each alloca 
explicitly in textual IR.  Having the type depend on the datalayout 
would be confusing, because you'd need to look at the datalayout to 
figure out which address-space the alloca in a snippet of IR uses.

Otherwise, this seems fine.

-Eli

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170316/3de377dd/attachment.html>

On 03/16/2017 12:51 PM, Arsenault, Matthew via llvm-dev
wrote:
>
> LLVM makes several assumptions about address space 0. However,
>
> alloca is presently constrained to always return this address space.
>
> There's no real way to avoid using alloca, so without this
>
> there is no way to opt out of these assumptions.
>
>
> The problematic assumptions include:
>
>   * That the pointer size used for the stack is the same size as the
>     code size pointer, which is also the maximum sized pointer.
>   * That 0 is an invalid, non-dereferencable pointer value.
>
> These are problems for AMDGPU because alloca is used to implement the 
> private address space, which uses a 32-bit index as the pointer value. 
> Other pointers are 64-bit and behave more like LLVM's notion of 
> generic address space. By changing the address space used for allocas, 
> we can change our generic pointer type to be LLVM's generic pointer 
> type which does have similar properties.
>
> The proposal here is to add a -A field to the datalayout string which 
> will specify the address space for allocas. IRBuilder::CreateAlloca 
> and company gain a DataLayout argument, and some intrinsics that 
> currently don't support address spaces need to support them.
>
> This has been implemented out of tree before before for CHERI.
>
> This has also been proposed before but for different reasons: 
> http://lists.llvm.org/pipermail/llvm-dev/2015-August/089706.html
>
>
> My current proposal is more focused than the previous proposal. 
> Instead of allowing specifying address spaces on individual allocas, 
> this restricts it to one chosen address space specified in the datalayout.
>
This sounds fine to me.

  -Hal
> I think the work to support different address spaces per-alloca is a 
> strict superset of this proposal, so if people are interested in that 
> I think that is a separate step beyond this.
>
>
> -Matt
>
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170316/692d0bf7/attachment.html>

On 03/16/2017 01:54 PM, Friedman, Eli via llvm-dev
wrote:
> On 3/16/2017 10:51 AM, Arsenault, Matthew via llvm-dev wrote:
>>
>> LLVM makes several assumptions about address space 0. However,
>>
>> alloca is presently constrained to always return this address space.
>>
>> There's no real way to avoid using alloca, so without this
>>
>> there is no way to opt out of these assumptions.
>>
>>
>> The problematic assumptions include:
>>
>>   * That the pointer size used for the stack is the same size as the
>>     code size pointer, which is also the maximum sized pointer.
>>   * That 0 is an invalid, non-dereferencable pointer value.
>>
>> These are problems for AMDGPU because alloca is used to implement the 
>> private address space, which uses a 32-bit index as the pointer 
>> value. Other pointers are 64-bit and behave more like LLVM's notion
>> of generic address space. By changing the address space used for 
>> allocas, we can change our generic pointer type to be LLVM's
generic
>> pointer type which does have similar properties.
>>
>> The proposal here is to add a -A field to the datalayout string which 
>> will specify the address space for allocas. IRBuilder::CreateAlloca 
>> and company gain a DataLayout argument, and some intrinsics that 
>> currently don't support address spaces need to support them.
>>
>
> I think we should also include the address-space of each alloca 
> explicitly in textual IR.  Having the type depend on the datalayout 
> would be confusing, because you'd need to look at the datalayout to 
> figure out which address-space the alloca in a snippet of IR uses.
Are we talking about this syntax?

   %i = alloca f32, align 4, addrspace 5

  -Hal
>
> Otherwise, this seems fine.
>
> -Eli
>
> -- 
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

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

On 03/16/2017 12:32 PM, Hal Finkel via llvm-dev wrote:
>
>
>
> On 03/16/2017 12:51 PM, Arsenault, Matthew via llvm-dev wrote:
>>
>> LLVM makes several assumptions about address space 0. However,
>>
>> alloca is presently constrained to always return this address space.
>>
>> There's no real way to avoid using alloca, so without this
>>
>> there is no way to opt out of these assumptions.
>>
>>
>> The problematic assumptions include:
>>
>>   * That the pointer size used for the stack is the same size as the
>>     code size pointer, which is also the maximum sized pointer.
>>   * That 0 is an invalid, non-dereferencable pointer value.
>>
>> These are problems for AMDGPU because alloca is used to implement the 
>> private address space, which uses a 32-bit index as the pointer 
>> value. Other pointers are 64-bit and behave more like LLVM's notion
>> of generic address space. By changing the address space used for 
>> allocas, we can change our generic pointer type to be LLVM's
generic
>> pointer type which does have similar properties.
>>
>> The proposal here is to add a -A field to the datalayout string which 
>> will specify the address space for allocas. IRBuilder::CreateAlloca 
>> and company gain a DataLayout argument, and some intrinsics that 
>> currently don't support address spaces need to support them.
>>
>> This has been implemented out of tree before before for CHERI.
>>
>> This has also been proposed before but for different reasons: 
>> http://lists.llvm.org/pipermail/llvm-dev/2015-August/089706.html
>>
>>
>> My current proposal is more focused than the previous proposal. 
>> Instead of allowing specifying address spaces on individual allocas, 
>> this restricts it to one chosen address space specified in the 
>> datalayout.
>>
>
> This sounds fine to me.
Seems reasonable to me as well. Stating that explicitly since I was one 
of the folks hesitant on the last proposal.  This one appears to have a 
more straight-forward justification.  Given we have two possible uses, 
even better.
>
>  -Hal
>
>> I think the work to support different address spaces per-alloca is a 
>> strict superset of this proposal, so if people are interested in that 
>> I think that is a separate step beyond this.
>>
>>
>> -Matt
>>
>>
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> -- 
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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