[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
> Managed language clients typically use address space 1 to represent
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...
More information about the llvm-dev