[llvm-dev] RFC: alloca -- specify address space for allocation

[David Chisnall via llvm-dev]

On 27 Aug 2015, at 07:40, Chandler Carruth via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> On Wed, Aug 26, 2015 at 8:25 PM Matt Arsenault <Matthew.Arsenault at amd.com> wrote:
> On 08/26/2015 07:02 PM, Chandler Carruth via llvm-dev wrote:
>> 
>> Without a better understanding of both the motivation and the resulting consequences such as what I've outlined in my questions above, it is very hard for me to feel comfortable with this kind of change.
>> 
> For my use case, some of the assumptions about addrspace(0) don't make any sense, so having the option of not using it for stack allocations would avoid some special case problems. For example, it's assumed that 0 is the address space of code, and stack, but for us these are unrelated concepts and have different pointer sizes. The assumption that 0 is not a valid pointer value is also incorrect, since we want stack pointers to be a 32-bit offset and 0 is valid. For this use case, all allocas should be created with the same address space, so it could be part of the datalayout. In the backend, we have 3 different memory types we would like to place stack objects, so being able to mark these with different address space IDs would also be helpful (although we wouldn't care about the middle end deciding that some allocas should be in a different address space from a single one specified by the data layout)
> 
> FWIW, these use cases seem really straight forward for address spaces. For example, I don't think any of my questions about the semantics apply. It seems straight forward to define a set of allowed address spaces for allocas in the data layout, and a default address space[1] for them that the optimizer could use if it creates or fuses allocas in ways that leave some ambiguity.

We have patches locally that allow you to specify the address space for allocas in the DataLayout, because in one of our ABIs the stack moves to a non-zero address space.  These would be relatively easy to extract, and if it’s an approach that would be useful then I could probably post them for review this week.

Having allocas in two address spaces seems plausible if they’re conceptually on different stacks, but using them for GC’d allocations seems odd, as you’d need to ensure that they were copied if live at the end of the stack frame, effectively turning the model into a collection of garbage collected activation records, rather than a stack.  For this use, I suspect that you’d need something more like a gc-alloca instruction, which could be promoted to an SSA register if its address isn’t taken, to a stack allocation if escape analysis can prove that pointers to it don’t persist beyond the end of the function, or to a GC’d heap allocation in other cases.

David