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

Philip Reames via llvm-dev llvm-dev at lists.llvm.org
Thu Aug 27 11:00:43 PDT 2015

On 08/26/2015 06:46 PM, Swaroop Sridhar 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.
This is not an entirely accurate statement.  There are currently one in 
tree GC strategy which uses addrspace(1) for this purpose and two out of 
tree GCs.  Its not really fair to say there's a convention established.
> 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'm not directly opposed to this proposal, but I'm not really in support 
of it either.  I think there a number of smaller engineering changes 
which could be made to RewriteStatepointsForGC to address this issue.  I 
am not convinced we need to allow addrspace on allocas to solve that 

More generally, I'm a bit bothered by how your asserting that a pointer 
to a stack based object is the same as a managed pointer into the heap.  
They share some properties - the GC needs to know about them and mark 
through them - but they're also moderately different as well - stack 
based objects do not get relocated, heap ones do.  Given this 
differences, it's not even entirely clear to me that these two classes 
of pointers should be treated the same.  In particular, I don't see why 
RewriteStatepointsForGC needs to insert explicit relocations for stack 
based objects.  That makes no sense to me.

I think it would help if we took a step back, summarized the 
requirements, and approached this anew.  I know that some of this has 
already been discussed off list, but given this has reached the point of 
making proposals to the community as a whole, I think the conversation 
needs be in public at this time.

(I'll also reply to a couple of specific points down thread.)

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

More information about the llvm-dev mailing list