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

Philip Reames via llvm-dev
Thu, 27 Aug 2015 20:31:23 -0000

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>