[llvm-dev] RFC: alloca -- specify address space for allocation
Chandler Carruth via llvm-dev
llvm-dev at lists.llvm.org
Fri Aug 28 02:01:25 PDT 2015
I completely agree with David and Philip here.
I think for the use case you are outlining, an addrspacecast is the correct
IR model -- you're specifically saying that it is OK in this case to turn a
pointer from addrspace 0 into one for addrspace N because N is your
"managed pointer" set that can be *either* a GC-pointer or a
non-GC-pointer. You might need N to be a distinct address space from the
one used for GC-pointers and to have similar casts emitted by the frontend.
What the FE is saying is that this is an *acceptable* transition of
addrspace, because your language and runtime semantics have provided for
it. I think the proper way to say that is with a cast.
I want to re-iterate though that there might be very reasonable uses for an
addrspace alloca to handle very different use cases such as modeling
different memory hierarchies. Those use cases have only been tangentially
discussed, so I don't feel like I have enough context to really comment on
them in any detail, and that entire discussion should probably be had on a
separate thread.
On Fri, Aug 28, 2015 at 1:55 AM David Chisnall <David.Chisnall at cl.cam.ac.uk>
wrote:
> On 28 Aug 2015, at 01:42, Swaroop Sridhar <Swaroop.Sridhar at microsoft.com>
> wrote:
> >
> > David: As I replied to some other messages on this thread, the intention
> is not
> > To garbage-collect stack locations, or the keep them alive beyond the
> stack's
> > natural lifetime.
>
> In that case, I think what you want to do can be represented by a stack
> allocation followed by an address space cast to AS 1 and pass that to the
> statepoint and then do an AS cast back after the statepoint.
>
> David
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150828/327c2751/attachment.html>
More information about the llvm-dev
mailing list