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

[Swaroop Sridhar via llvm-dev]

> -----Original Message-----
> From: Hal Finkel [mailto:hfinkel at anl.gov]
> Sent: Wednesday, August 26, 2015 7:43 PM
> To: Swaroop Sridhar <Swaroop.Sridhar at microsoft.com>
> Cc: 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
> 
> ----- Original Message -----
> > From: "Swaroop Sridhar via llvm-dev" <llvm-dev at lists.llvm.org>
> > To: "llvm-dev" <llvm-dev at lists.llvm.org>, "Philip Reames"
> <listmail at philipreames.com>, "Sanjoy Das"
> > <sanjoy at playingwithpointers.com>
> > Sent: Wednesday, August 26, 2015 8:46:08 PM
> > Subject: [llvm-dev] RFC: alloca -- specify address space for
> > allocation
> >
> > 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.
> >
> 
> Is the mental model here that a function using this feature actually has
> multiple stacks, in different address spaces, and this allows creating local
> stack allocations in those non-addrspace-0 stacks?
> 
> Would there be any defined interaction with
> @llvm.stacksave/@llvm.stackrestore?
> 
> Normally we assume that distinct allocas can't alias, but what about allocas
> with different address spaces? Can they alias?

Hi Finkel, 

Yes, we can conceptualize the model as multiple stacks in different address-spaces.
Apart from this, there should be no impact on layout. Two distinct allocas can still not alias each other. 

Swaroop.