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

[Swaroop Sridhar via llvm-dev]

> -----Original Message-----
> From: Dr D. Chisnall [mailto:dc552 at hermes.cam.ac.uk] On Behalf Of David
> Chisnall
> Sent: Thursday, August 27, 2015 2:26 AM
> To: Chandler Carruth <chandlerc at google.com>
> Cc: Matt Arsenault <Matthew.Arsenault at amd.com>; Swaroop Sridhar
> <Swaroop.Sridhar at microsoft.com>; llvm-dev <llvm-dev at lists.llvm.org>;
> Philip Reames <listmail at philipreames.com>; Sanjoy Das
> <sanjoy at playingwithpointers.com>
> Subject: Re: [llvm-dev] RFC: alloca -- specify address space for allocation
> 
> 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: As I replied to some other messages on this thread, the intention is not 
To garbage-collect stack locations, or the keep them alive beyond the stack's 
natural lifetime.  

Only change is to type the pointer to the alloca'ed memory to be compatible 
with gc-pointer type, to facilitate their interoperability.