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

[Swaroop Sridhar via llvm-dev]

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>