[llvm-dev] RFC: alloca -- specify address space for allocation
Hal Finkel via llvm-dev
llvm-dev at lists.llvm.org
Wed Aug 26 19:43:24 PDT 2015
----- 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
> Managed language clients typically use address space 1 to represent
> 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
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 @email@example.com?
Normally we assume that distinct allocas can't alias, but what about allocas with different address spaces? Can they alias?
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
More information about the llvm-dev