llvm dev - Aug 2015 - 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

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

On 28 Aug 2015, at 01:42, Swaroop Sridhar <Swaroop.Sridhar at
microsoft.com> wrote:
> 
> 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.  
In that case, I think what you want to do can be represented by a stack
allocation followed by an address space cast to AS 1 and pass that to the
statepoint and then do an AS cast back after the statepoint.

David