[LLVMdev] GC questions.
spyck at lysator.liu.se
Mon Jul 19 07:42:49 PDT 2004
On Mon, 19 Jul 2004, Chris Lattner wrote:
> On Mon, 19 Jul 2004, Tobias Nurmiranta wrote:
> > Regarding llvm.gcroot, do I have to allocate stack-space for all
> > pointers in a function? Right now I mostly use SSA-variables, and let
> > llvm's register allocation allocate stack-space when needed.
> Yes. This reflects the fact that the GC can move objects (to compact the
> heap) at unpredictable times.
> > Also, what happens when I run the mem2reg pass, does it handle
> > llvm.gcroot's that are moved from stack to registers?
> Not currently. In the future this will definitely be improved. In
> particular, when the code generators are enhanced to provide more accurate
> mapping information for GC pointers (e.g. which registers contain
> pointers), we can do this. This is in the long term plans, but I suspect
> that performance will be fine without it for many applications.
How are pointers to heap-data in registers handled right now? Or am I only
allowed to use pointers indirectly through the stack?
> > I'm thinking along the lines, that should one not use llvm.gcroot on all
> > SSA-variables that contains pointers to objects, and then depending on
> > if the variables end up on the stack, or in registers, the compiler will
> > use llvm.gcroot?
> llvm.gcroot is an abstraction. Your front-end is telling the code
> generator and optimizer what locations can be modified unpredictably at
> runtime by the GC system. Right now we do not have many clients of the
> gc interfaces, so they do not produce wonderful code, but this will change
> in time. :)
Ok, I guess it in the future would be nice if the llvm.gcroot abstraction
could be applied to SSA-variables as well as the stack, and then
transformed by the compiler.
Is the code available for any of these clients?
More information about the llvm-dev