[LLVMdev] GC questions.

Tobias Nurmiranta 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?

,	Tobias

More information about the llvm-dev mailing list