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

Marcello Maggioni via llvm-dev
Thu, 27 Aug 2015 04:40:04 -0000

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>