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

[Chandler Carruth via llvm-dev]

On Wed, Aug 26, 2015 at 6:46 PM Swaroop Sridhar via llvm-dev <
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)...

- Can I promote such a location to an SSA register?
- What does it mean to collect a stack location?
- 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?

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
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150827/4c2fe52c/attachment.html>