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

Friedman, Eli via llvm-dev llvm-dev at lists.llvm.org
Thu Mar 16 11:54:38 PDT 2017


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>


More information about the llvm-dev mailing list