thr3ads.net - llvm dev - [llvm-dev] RFC: alloca -- specify address space for allocation [Aug 2015]

If this information is useful, please help other people find it:
Share via:

Swaroop Sridhar via llvm-dev

2015-Aug-27 03:39 UTC

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

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>

Marcello Maggioni via llvm-dev

2015-Aug-27 04:40 UTC

head link

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

It is not clear to me if these GC pointers are actually living in a different
address space when allocated on the stack (aka. you have two different stacks)
or if the address space is just a way to mark that that pointer is a GC-pointer
, but all the stack allocation actually lives in the same address space
(presumably 0).

Marcello> On 26 Aug 2015, at 20:39, Swaroop Sridhar via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Please see inline.
>  
> From: Chandler Carruth [mailto:chandlerc at google.com <mailto:chandlerc
at google.com>]
> Sent: Wednesday, August 26, 2015 7:03 PM
> To: Swaroop Sridhar <Swaroop.Sridhar at microsoft.com
<mailto:Swaroop.Sridhar at microsoft.com>>; llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>>; Philip Reames
<listmail at philipreames.com <mailto:listmail at
philipreames.com>>; Sanjoy Das <sanjoy at playingwithpointers.com
<mailto: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://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttp-253a-252f-252flists.llvm.org-252fcgi-2Dbin-252fmailman-252flistinfo-252fllvm-2Ddev-26data-3D01-257c01-257cSwaroop.Sridhar-2540microsoft.com-257c58ded8bf3e5141b4884c08d2ae839898-257c72f988bf86f141af91ab2d7cd011db47-257c1-26sdata-3DxY2wWEhcEGdjQtcEqzSAXstTDgFW-252fxPl4RhJIDYQCCY-253d&d=BQMGaQ&c=eEvniauFctOgLOKGJOplqw&r=THu9ANfN9LYlQTYNQdmA7D-MsdMl2OioTAKXjMfn7i4&m=rPG5Brg7MCC-dk2NfmVIUdydnG-sBY4i5vxuuhfMjn4&s=JKA46T4ShURRYPiglJdaLfv4njMVPeb-zf_i0CiLfbw&e=>_______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=THu9ANfN9LYlQTYNQdmA7D-MsdMl2OioTAKXjMfn7i4&m=rPG5Brg7MCC-dk2NfmVIUdydnG-sBY4i5vxuuhfMjn4&s=GWkPE5c8T8RLUaT_ef53yhM_NZqIhsE2Kyze3P8Rf3s&e=
<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=THu9ANfN9LYlQTYNQdmA7D-MsdMl2OioTAKXjMfn7i4&m=rPG5Brg7MCC-dk2NfmVIUdydnG-sBY4i5vxuuhfMjn4&s=GWkPE5c8T8RLUaT_ef53yhM_NZqIhsE2Kyze3P8Rf3s&e=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150826/e9f95fab/attachment.html>

Philip Reames via llvm-dev

2015-Aug-27 20:31 UTC

head link

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

As a bit of background, the reason we originally went with addrspaces to 
mark GC pointers was that the managed and non-managed heaps for us are 
semantically non-overlapping.   It's not entirely clear to me that the 
notion of two non-overlapping stacks is the right mental model for 
approaching the stack allocated object portion.

Philip

On 08/26/2015 09:40 PM, Marcello Maggioni wrote:> It is not clear to me if these GC pointers are actually living in a 
> different address space when allocated on the stack (aka. you have two 
> different stacks) or if the address space is just a way to mark that 
> that pointer is a GC-pointer , but all the stack allocation actually 
> lives in the same address space (presumably 0).
>
> Marcello
>> On 26 Aug 2015, at 20:39, Swaroop Sridhar via llvm-dev 
>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>> wrote:
>>
>> 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 
>> <mailto:Swaroop.Sridhar at microsoft.com>>; llvm-dev 
>> <llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>>; Philip
>> Reames <listmail at philipreames.com 
>> <mailto:listmail at philipreames.com>>; Sanjoy Das 
>> <sanjoy at playingwithpointers.com <mailto: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, theallocainstruction always allocates in the generic
>>     address space (0).
>>     This proposal is to extend the semantics ofallocainstruction 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 anaddrespace(1)*pointer to a stack location currently
>>     involves two steps: thealloca, and anaddrspacecast.
>>     Managed code transformations (ex:RewriteStatepointsForGC) do not
>>     handle arbitrary address space casting.
>>     So, it is desirable to obtain theaddrespace(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:
>> publicclassObj{ publicint i; }
>> publicstaticint Test() {
>> Obj obj = newObj();
>> inti=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://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttp-253a-252f-252flists.llvm.org-252fcgi-2Dbin-252fmailman-252flistinfo-252fllvm-2Ddev-26data-3D01-257c01-257cSwaroop.Sridhar-2540microsoft.com-257c58ded8bf3e5141b4884c08d2ae839898-257c72f988bf86f141af91ab2d7cd011db47-257c1-26sdata-3DxY2wWEhcEGdjQtcEqzSAXstTDgFW-252fxPl4RhJIDYQCCY-253d&d=BQMGaQ&c=eEvniauFctOgLOKGJOplqw&r=THu9ANfN9LYlQTYNQdmA7D-MsdMl2OioTAKXjMfn7i4&m=rPG5Brg7MCC-dk2NfmVIUdydnG-sBY4i5vxuuhfMjn4&s=JKA46T4ShURRYPiglJdaLfv4njMVPeb-zf_i0CiLfbw&e=>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>>
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=THu9ANfN9LYlQTYNQdmA7D-MsdMl2OioTAKXjMfn7i4&m=rPG5Brg7MCC-dk2NfmVIUdydnG-sBY4i5vxuuhfMjn4&s=GWkPE5c8T8RLUaT_ef53yhM_NZqIhsE2Kyze3P8Rf3s&e>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150827/15911a43/attachment.html>

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

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

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

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