[llvm-dev] RFC: alloca -- specify address space for allocation
Swaroop Sridhar via llvm-dev
llvm-dev at lists.llvm.org
Thu Aug 27 16:24:34 PDT 2015
From: Philip Reames [mailto:listmail at philipreames.com]
Sent: Thursday, August 27, 2015 11:01 AM
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
>>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.
OK Thanks for the correction.
Basically, the intention here is that there exists some GC-strategy that uses address-space annotation to differentiate gc-pointers from native-pointers.
> 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 problem.
> 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.
Yes pointers to the stack are different in that they are not relocated or collected.
However, CLR's "managed pointers" are defined as a super-type of pointers-to-the GC-heap and pointers-to-unmanaged-memory.
These managed pointers should be reported to the GC. They will be updated during a collection relocated if the referenced object is relocated.
Wrt the RewriteStatepointsForGC phase:
If we know that a particular managed pointer is definitely coming from an alloca, it is OK to not report it, and not insert relocations.
However, sometimes we cannot tell this unambiguously, if a managed pointer comes from a PHI(alloca pointer, heap pointer).
> I think it would help if we took a step back, summarized the requirements, and approached this anew.
The real requirement we have is: A way to construct a managed pointer to a stack location (or any other unmanaged location) such that it is interoperable with other GC pointers.
The way we do it currently is using addrspacecast:
%loc0 = alloca i8
%1 = addrspacecast i8* %loc0 to i8 addrspace(1)*
I'm wondering if:
(a) There is a better way to do this to better suite managed-code analysis/transformation phases, and
(b) If generating the managed-pointer by construction alloca addrspace(1)* is the way to do it.
More information about the llvm-dev