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

[Swaroop Sridhar via llvm-dev]

Inline.

From: Philip Reames [mailto:listmail at philipreames.com] 
Sent: Thursday, August 27, 2015 1:27 PM
To: Chandler Carruth <chandlerc at google.com>; Swaroop Sridhar <Swaroop.Sridhar at microsoft.com>; llvm-dev <llvm-dev at lists.llvm.org>; Sanjoy Das <sanjoy at playingwithpointers.com>
Subject: Re: [llvm-dev] RFC: alloca -- specify address space for allocation
 
>- 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.  

Yes, the semantics of alloca with a non-zero address-space specification should behave similar to the regular alloca, followed by a cast of the pointer to that address-space.
The intention is to use the address-space region annotation to add to the type specification. Apart from this, stack layout should not be affected.

The aliasing properties are also not expected to be any different from other addrspace(0) or addrspace(1) pointers.
Maybe I'm not appreciating the aliasing concern here -- Can you please give an example? 

Swaroop.