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

[Hal Finkel via llvm-dev]

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>