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

[Hal Finkel via llvm-dev]

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>