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

[Philip Reames via llvm-dev]

On 08/26/2015 07:02 PM, Chandler Carruth wrote:
> On Wed, Aug 26, 2015 at 6:46 PM Swaroop Sridhar via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>
>     Currently, the alloca instruction always allocates in the generic
>     address space (0).
>
>     This proposal is to extend the semantics of alloca instruction to
>     allow allocation in any specified address space.
>
>     *Proposed Syntax*
>
>     <result> = alloca [inalloca] <type> [, <ty> <NumElements>] [,
>     align <alignment>] *[, addrspace <num>]* ; yields type
>     addrspace(num)*:result
>
>     *Motivation*
>
>     Managed language clients typically use address space 1 to
>     represent GC-pointers.
>
>     Some managed clients (CLR, in particular) allow construction of GC
>     pointers to stack locations.
>
>     For example, MSIL instruction ldloca (ECMA 335, p 370) creates a
>     GC pointer to a stack local.
>
>     Creating an addrespace(1)* pointer to a stack location currently
>     involves two steps: the alloca, and an addrspacecast.
>
>     Managed code transformations (ex: RewriteStatepointsForGC) do not
>     handle arbitrary address space casting.
>
>     So, it is desirable to obtain the addrespace(1)* pointer by
>     construction.
>
> I don't have a particular or specific objection here necessarily, but 
> I have to admit I don't understand the use case (yet). I'm hoping you 
> can explain it to me more thoroughly.
>
> What semantics do you expect for GC pointer to a stack location? 
> That's what I don't really understand. Some questions that leap to 
> mind, but may be the wrong questions (so feel free to point me in the 
> right direction here)...
>
> - Can I promote such a location to an SSA register?
> - What does it mean to collect a stack location?
> - Can I merge stack allocations that are GC pointers? Can I re-use 
> them? What semantics do I get?
> - Do GC pointers to stack locations have any different aliasing 
> properties?
> - When the optimizer needs to create a new stack allocation, what 
> address space should it be in?
For the proposed solution, what I think Swaroop is going for is simply 
having a mechanism to distinguish some allocas from others without 
otherwise effecting code generation.  They are still stack based 
objects; they don't escape unless unused at a safepoint; they're not 
relocated.  They may contain pointers to objects which do need to be 
relocated, so we need to have a mechanism to track them.  In particular, 
it would be perfectly legal to promote to SSA since the interior 
pointers would become addrspace(1) SSA values and be handled correctly 
by the relocation logic.

I can't answer the merging question above.  There are entirely sane 
semantics which could be assigned to stack allocation merging, but I'm 
not sure what expectations the CLR GCs have.

Swaroop - If I've misstated anything above, please correct me.

>
> Ultimately, to make this change, you'll also need to change a decent 
> amount of code in the optimizer that will blindly create stack 
> allocations in address space zero.
>
> 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.
This is basically my reaction as well.  This seems like a big hammer to 
a problem I'm not sure is actually a nail.
>
>     Thanks,
>
>     Swaroop.
>
>     _______________________________________________
>     LLVM Developers mailing list
>     llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>

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