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

[Friedman, Eli via llvm-dev]

On 3/16/2017 12:41 PM, Hal Finkel wrote:
>
> 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

Something like that, yes, I think.

-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/ba8e8191/attachment.html>