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

Swaroop Sridhar via llvm-dev
Thu, 27 Aug 2015 03:39:38 -0000

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>