[llvm-dev] RFC: alloca -- specify address space for allocation
Swaroop Sridhar via llvm-dev
llvm-dev at lists.llvm.org
Thu Aug 27 14:40:20 PDT 2015
Philip: I think there are two separate issues:
1) Handling GC pointers stored in stack locations -- tracking their liveness, reporting them to the GC. etc.
2) Treating pointers to stack locations as GC-pointers.
I think the two options that you presented here are for solving (1).
I'm trying to solve issue (2) using alloca in addrspace(1).
Basically, we want to create a pointer to a stack location (the location itself may not have any gc-pointers) and give it a type such that it can be used interchangeably with GC-pointers.
Today, we can achieve this by using an alloca followed by an addrspacecast. It could be done in one instruction if the alloca can specify the addrspace of the pointer created.
The advantage of doing this in one step is, for example, that we can check that there are no (other) addrspace(0) -> addrspace(1) casts.
(introduced inadvertently by user code or compiler transformations).
From: Philip Reames [mailto:listmail at philipreames.com]
Sent: Thursday, August 27, 2015 1:47 PM
To: Swaroop Sridhar <Swaroop.Sridhar at microsoft.com>; llvm-dev <llvm-dev at lists.llvm.org>; Sanjoy Das <sanjoy at playingwithpointers.com>
Cc: Joseph Tremoulet <jotrem at microsoft.com>; Andy Ayers <andya at microsoft.com>; Russell Hadley <rhadley at microsoft.com>
Subject: Re: RFC: alloca -- specify address space for allocation
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.
<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 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.
More information about the llvm-dev