[llvm-dev] RFC: alloca -- specify address space for allocation
Philip Reames via llvm-dev
llvm-dev at lists.llvm.org
Thu Aug 27 13:46:43 PDT 2015
For the record, at least two other implementation strategies to address
the original problem have been discussed.
Option 1 (Rejected) - Explode the stack based object into individual
fields individual fields before the safepoint and store them back into
the alloca afterwards. Only the exploded SSA values would get listed in
the stackmap. This could work today, but does not meet a functional
requirement. A pointer to a stack based object can be escaped and a
callee (or another thread) can write to the field location. As a
result, the reform of the stack based object after the safepoint can
introduce writes which didn't exist in the original program.
Option 2 - Consider pointers within stack based objects (allocas in
addrspace 0) as being live and add their addresses (not values) to the
stackmap. This could be done by extending the liveness analysis already
in RewriteStatepointsForGC to consider allocas containing pointers.
There wouldn't be any addrspace casts involved since the members of the
stack based object are addrspace(1) pointers to start with. Loading
them produces an SSA value which can be relocated as usual. I don't
remember hearing a clearly expressed reason why this doesn't work. I
believe there were some concerns about the density/size of the generated
stack maps, but I haven't seen any evaluation of this.
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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev