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

Thu Aug 27 13:31:23 PDT 2015

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>