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

[Philip Reames via llvm-dev]

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
>
> *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.
>
> Thanks,
>
> Swaroop.
>

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