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

[Philip Reames via llvm-dev]

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>