[llvm-dev] RFC: alloca -- specify address space for allocation
Swaroop Sridhar via llvm-dev
llvm-dev at lists.llvm.org
Thu Aug 27 17:43:04 PDT 2015
> -----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
> Normally we assume that distinct allocas can't alias, but what about allocas
> with different address spaces? Can they alias?
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.
More information about the llvm-dev