llvm dev - Aug 2015 - RFC: alloca -- specify address space for allocation

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/9debdc4c/attachment-0001.html>

On 08/26/2015 06:46 PM, Swaroop Sridhar via llvm-dev
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.
>
>
+1.

It would be useful to fully avoid all of the special semantics that 
addrspace(0) implies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150826/145685d2/attachment.html>

On Wed, Aug 26, 2015 at 6:46 PM Swaroop Sridhar via llvm-dev <
llvm-dev at lists.llvm.org> 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.
>
I don't have a particular or specific objection here necessarily, but I
have to admit I don't understand the use case (yet). I'm hoping you can
explain it to me more thoroughly.

What semantics do you expect for GC pointer to a stack location? That's
what I don't really understand. Some questions that leap to mind, but may
be the wrong questions (so feel free to point me in the right direction
here)...

- Can I promote such a location to an SSA register?
- What does it mean to collect a stack location?
- Can I merge stack allocations that are GC pointers? Can I re-use them?
What semantics do I get?
- Do GC pointers to stack locations have any different aliasing properties?
- When the optimizer needs to create a new stack allocation, what address
space should it be in?

Ultimately, to make this change, you'll also need to change a decent amount
of code in the optimizer that will blindly create stack allocations in
address space zero.

Without a better understanding of both the motivation and the resulting
consequences such as what I've outlined in my questions above, it is very
hard for me to feel comfortable with this kind of change.
>
>
> Thanks,
>
> Swaroop.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150827/4c2fe52c/attachment.html>

----- Original Message -----
> From: "Swaroop Sridhar via llvm-dev" <llvm-dev at
lists.llvm.org>
> To: "llvm-dev" <llvm-dev at lists.llvm.org>, "Philip
Reames" <listmail at philipreames.com>, "Sanjoy Das"
> <sanjoy at playingwithpointers.com>
> Sent: Wednesday, August 26, 2015 8:46:08 PM
> Subject: [llvm-dev] RFC: alloca -- specify address space for allocation
> 
> 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.
> 
Is the mental model here that a function using this feature actually has
multiple stacks, in different address spaces, and this allows creating local
stack allocations in those non-addrspace-0 stacks?

Would there be any defined interaction with @llvm.stacksave/@llvm.stackrestore?

Normally we assume that distinct allocas can't alias, but what about allocas
with different address spaces? Can they alias?

 -Hal 
> 
> 
> Thanks,
> 
> Swaroop.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

On 08/26/2015 07:02 PM, Chandler Carruth via llvm-dev
wrote:
>
> Without a better understanding of both the motivation and the 
> resulting consequences such as what I've outlined in my questions 
> above, it is very hard for me to feel comfortable with this kind of 
> change.
>
For my use case, some of the assumptions about addrspace(0) don't make 
any sense, so having the option of not using it for stack allocations 
would avoid some special case problems. For example, it's assumed that 0 
is the address space of code, and stack, but for us these are unrelated 
concepts and have different pointer sizes. The assumption that 0 is not 
a valid pointer value is also incorrect, since we want stack pointers to 
be a 32-bit offset and 0 is valid. For this use case, all allocas should 
be created with the same address space, so it could be part of the 
datalayout. In the backend, we have 3 different memory types we would 
like to place stack objects, so being able to mark these with different 
address space IDs would also be helpful (although we wouldn't care about 
the middle end deciding that some allocas should be in a different 
address space from a single one specified by the data layout)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150826/2189a9ac/attachment.html>

Please see inline.

From: Chandler Carruth [mailto:chandlerc at google.com]
Sent: Wednesday, August 26, 2015 7:03 PM
To: Swaroop Sridhar <Swaroop.Sridhar at microsoft.com>; llvm-dev
<llvm-dev at lists.llvm.org>; Philip Reames <listmail at
philipreames.com>; Sanjoy Das <sanjoy at playingwithpointers.com>
Subject: Re: [llvm-dev] RFC: alloca -- specify address space for allocation

On Wed, Aug 26, 2015 at 6:46 PM Swaroop Sridhar via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> 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.
I don't have a particular or specific objection here necessarily, but I have
to admit I don't understand the use case (yet). I'm hoping you can
explain it to me more thoroughly.

What semantics do you expect for GC pointer to a stack location? That's what
I don't really understand. Some questions that leap to mind, but may be the
wrong questions (so feel free to point me in the right direction here)...

CLR defines the a kind of GC pointer called “managed pointer” , which can point
to a local variable, heap object, parameter, field of a compound type, or
element of an array. The semantics of managed pointer is liberally defined to
support by-reference passing. For example, in this C# example:


public class Obj { public int i; }

public static int Test() {
  Obj obj = new Obj();
  int i=0;
  …

  if(cond) {
    Fn(ref i);     // managed pointer to a stack location
  }
  else {
    Fn(ref obj.i); // managed pointer to a heap location
  }
}

- Can I promote such a location to an SSA register?

The rules for the stack location is the same as any address-taken location.
I don’t think the fact that the generated address is a managed pointer should
make a difference.

- What does it mean to collect a stack location?

The stack location is not GCed or relocated.
For a reported managed pointer, if the referenced location is outside the bounds
of the GC-heap, the runtime leaves it alone.

- Can I merge stack allocations that are GC pointers? Can I re-use them? What
semantics do I get?
- Do GC pointers to stack locations have any different aliasing properties?
- When the optimizer needs to create a new stack allocation, what address space
should it be in?

I’ll answer these questions in my next email.

Ultimately, to make this change, you'll also need to change a decent amount
of code in the optimizer that will blindly create stack allocations in address
space zero.

Without a better understanding of both the motivation and the resulting
consequences such as what I've outlined in my questions above, it is very
hard for me to feel comfortable with this kind of change.

Thanks,
Swaroop.
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2flists.llvm.org%2fcgi-bin%2fmailman%2flistinfo%2fllvm-dev&data=01%7c01%7cSwaroop.Sridhar%40microsoft.com%7c58ded8bf3e5141b4884c08d2ae839898%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=xY2wWEhcEGdjQtcEqzSAXstTDgFW%2fxPl4RhJIDYQCCY%3d>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150827/d591a71f/attachment-0001.html>

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.
>
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.
>
> 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.
>
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.

I think it would help if we took a step back, summarized the 
requirements, and approached this anew.  I know that some of this has 
already been discussed off list, but given this has reached the point of 
making proposals to the community as a whole, I think the conversation 
needs be in public at this time.

(I'll also reply to a couple of specific points down thread.)

Philip
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150827/86bb120a/attachment-0001.html>

On 08/26/2015 07:02 PM, Chandler Carruth wrote:
> On Wed, Aug 26, 2015 at 6:46 PM Swaroop Sridhar via llvm-dev 
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> 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.
>
> I don't have a particular or specific objection here necessarily, but 
> I have to admit I don't understand the use case (yet). I'm hoping
you
> can explain it to me more thoroughly.
>
> What semantics do you expect for GC pointer to a stack location? 
> That's what I don't really understand. Some questions that leap to 
> mind, but may be the wrong questions (so feel free to point me in the 
> right direction here)...
>
> - Can I promote such a location to an SSA register?
> - What does it mean to collect a stack location?
> - Can I merge stack allocations that are GC pointers? Can I re-use 
> them? What semantics do I get?
> - Do GC pointers to stack locations have any different aliasing 
> properties?
> - When the optimizer needs to create a new stack allocation, what 
> address space should it be in?
For the proposed solution, what I think Swaroop is going for is simply 
having a mechanism to distinguish some allocas from others without 
otherwise effecting code generation.  They are still stack based 
objects; they don't escape unless unused at a safepoint; they're not 
relocated.  They may contain pointers to objects which do need to be 
relocated, so we need to have a mechanism to track them.  In particular, 
it would be perfectly legal to promote to SSA since the interior 
pointers would become addrspace(1) SSA values and be handled correctly 
by the relocation logic.

I can't answer the merging question above.  There are entirely sane 
semantics which could be assigned to stack allocation merging, but I'm 
not sure what expectations the CLR GCs have.

Swaroop - If I've misstated anything above, please correct me.
>
> Ultimately, to make this change, you'll also need to change a decent 
> amount of code in the optimizer that will blindly create stack 
> allocations in address space zero.
>
> Without a better understanding of both the motivation and the 
> resulting consequences such as what I've outlined in my questions 
> above, it is very hard for me to feel comfortable with this kind of 
> change.
This is basically my reaction as well.  This seems like a big hammer to 
a problem I'm not sure is actually a nail.
>
>     Thanks,
>
>     Swaroop.
>
>     _______________________________________________
>     LLVM Developers mailing list
>     llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>     http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150827/2e710fb2/attachment.html>

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>

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).

Swaroop.
 

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.
 
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.

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.

> -----Original Message-----
> From: Hal Finkel [mailto:hfinkel at anl.gov]
> Sent: Wednesday, August 26, 2015 7:43 PM
> To: Swaroop Sridhar <Swaroop.Sridhar at microsoft.com>
> Cc: llvm-dev <llvm-dev at lists.llvm.org>; Philip Reames
> <listmail at philipreames.com>; Sanjoy Das
> <sanjoy at playingwithpointers.com>
> Subject: Re: [llvm-dev] RFC: alloca -- specify address space for allocation
> 
> ----- Original Message -----
> > From: "Swaroop Sridhar via llvm-dev" <llvm-dev at
lists.llvm.org>
> > To: "llvm-dev" <llvm-dev at lists.llvm.org>,
"Philip Reames"
> <listmail at philipreames.com>, "Sanjoy Das"
> > <sanjoy at playingwithpointers.com>
> > Sent: Wednesday, August 26, 2015 8:46:08 PM
> > Subject: [llvm-dev] RFC: alloca -- specify address space for
> > allocation
> >
> > 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.
> >
> 
> Is the mental model here that a function using this feature actually has
> multiple stacks, in different address spaces, and this allows creating
local
> stack allocations in those non-addrspace-0 stacks?
> 
> Would there be any defined interaction with
> @llvm.stacksave/@llvm.stackrestore?
> 
> Normally we assume that distinct allocas can't alias, but what about
allocas
> with different address spaces? Can they alias?
Hi Finkel, 

Yes, we can conceptualize the model as multiple stacks in different
address-spaces.
Apart from this, there should be no impact on layout. Two distinct allocas can
still not alias each other.

Swaroop.