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

[Swaroop Sridhar via llvm-dev]

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.