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

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.

-Matt

This is exactly what we do for CHERI (one address space for all allocas) and the changes are quite small. If they’re useful, please feel free to pull them out from our tree - we’ve just done a merge from upstream, so they should apply cleanly.

David

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.

This sounds fine to me. -Hal

Are we talking about this syntax? %i = alloca f32, align 4, addrspace 5 -Hal

Something like that, yes, I think. -Eli

Seems reasonable to me as well. Stating that explicitly since I was one of the folks hesitant on the last proposal. This one appears to have a more straight-forward justification. Given we have two possible uses, even better.