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.> 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. :)> All my objects are currently typetagged uint's. My llvm scheme code in > the compiler explains this I think:I think that this should be fine. The GC interfaces are explicitly designed to be able to support list/scheme style type tagging like this, thought the current garbage collector is not fully implemented. -Chris> (llvm-define (make-number x) (bit-shl x 2)) > (llvm-define (raw-number x) (bit-shr x 2)) > (llvm-define (clear-tag x) (bit-shl (bit-shr x 2) 2)) > (llvm-define (get-tag x) (bit-and x 3)) > (llvm-define (make-pointer x) (bit-or (clear-tag x) 1)) > (llvm-define (make-function-pointer x) (bit-or (clear-tag x) 3)) > (llvm-define (points-to x) (clear-tag x)) > (llvm-define (number? x) (seteq (get-tag x) 0)) > (llvm-define (vector? x) (seteq (get-tag x) 1)) > (llvm-define (procedure? x) (seteq (get-tag x) 3)) > > (llvm-define (make-vector raw-size) > (make-pointer > (cast "uint*" (store raw-size (malloc (add raw-size 1))) "uint"))) > > , Tobias > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev >-Chris -- http://llvm.cs.uiuc.edu/ http://nondot.org/sabre/
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
On Mon, 19 Jul 2004, Tobias Nurmiranta wrote:> > 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?Unfortunately we don't have any front-ends using the GC currently (though several are in progress of being developed). The idea is to have a call-back, provided by the front-end, which provides pointer mapping information. In the Java-style world, this hook would look at the type-information hanging off of the object vtable to know where the pointers are in the object. In a scheme world, this hook could look at the elements directly and "know" whether they are pointers (based on bit-patterns).> > 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.Yes, it will be.> Is the code available for any of these clients?llvm-java is in public CVS, but it is not GC enabled. Unfortunately, the GC implementation is not 100% complete, but it does give you all of the information you need from the code generator (the ability to identify and modify roots on the stack). -Chris -- http://llvm.cs.uiuc.edu/ http://nondot.org/sabre/