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

Swaroop Sridhar via llvm-dev
Thu, 27 Aug 2015 23:24:34 -0000

Inline.

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.

Thanks,
Swaroop.