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

Arsenault, Matthew via llvm-dev llvm-dev at lists.llvm.org
Thu Mar 16 10:51:57 PDT 2017

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. 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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170316/ba053008/attachment.html>

More information about the llvm-dev mailing list