search for: collectorregistry

...gistry. I haven't converted anything else to use it, though. Still, it's orthogonal and has become stable in my usage, so I thought I'd submit it in advance. To get my collector registry going, all I needed was 5 lines: // GCRegistry.h typedef Registry<TargetCollector> CollectorRegistry; // GCRegistry.cpp template<> CollectorRegistry::node *CollectorRegistry::Head = 0; template<> CollectorRegistry::node *CollectorRegistry::Tail = 0; template<> CollectorRegistry::listener *CollectorRegistry::ListenerHead = 0; template<> CollectorRegistry::l...

Hey, I am a bit confused about the CollectorRegistry. I am attempting to write a garbage collector for LLVM, and the tiny example in the docs at http://llvm.org/releases/2.3/docs/GarbageCollection.html gives this line: CollectorRegistry::Add<MyCollector> X("mygc", "My bespoke garbage collector."); My question is now: A...

On 2008-07-23, at 08:58, Simon Ask Ulsnes wrote: > I am attempting to write a garbage collector for LLVM, and the tiny > example in the docs at http://llvm.org/releases/2.3/docs/GarbageCollection.html > gives this line: > > CollectorRegistry::Add<MyCollector> > X("mygc", "My bespoke garbage collector."); > > My question is now: Am I supposed to instantiate my collector > manually, and tell LLVM about it, or can the Registry instantiate > it, and it that case, how to go about that? I haven&...

...similar to lli that loads in bitcode and my GC, and executes it, and ideally programs would be able to use the GC without needing bitcode-level modifications (it's perfectly ok to have to replace calls to malloc, though). > > This string must correspond to the first argument to the > CollectorRegistry::Add<> constructor. > > The second argument to the constructor is, I think, "purely > informational" for collectors. For the related TargetMachineRegistry, > the second argument appears in --help output. > > Hope that helps, > Gordon It helps a lot. Thank you f...

On Jul 24, 2008, at 03:10, Simon Ask Ulsnes wrote: >> I would say that accurate GC would generally require considerable >> cooperation from the front-end compiler, which GCC does not >> particularly provide. But you could experiment with it. Simply >> adding a GC attribute to an existing function should generally be >> harmless (e.g., the inliner will do so

2008/7/24 Gordon Henriksen <gordonhenriksen at me.com>: >> OK, so for instance if I wanted to be able to use the GC from a C >> frontend (presumably by using llvm_gc_allocate?), do the C functions >> need this attribute as well? > > Yes. I forgot I still needed an answer to my original question. :-P So, I have to implement llvm_gc_initialize, llvm_gc_allocate, and

On Jul 26, 2008, at 10:32, Simon Ask Ulsnes wrote: > I forgot I still needed an answer to my original question. :-P > > So, I have to implement llvm_gc_initialize, llvm_gc_allocate, and > llvm_gc_collect Yes. Your implementation of the llvm_gc_* functions should be compiled into a library and linked with your executable. > (llvm_cg_walk_gcroots is provided by the Collector

> I would say that accurate GC would generally require considerable > cooperation from the front-end compiler, which GCC does not > particularly provide. But you could experiment with it. Simply adding > a GC attribute to an existing function should generally be harmless > (e.g., the inliner will do so inlining a function with GC into a > function without), but doing so won't

On 2008-07-23, at 11:48, Simon Ask Ulsnes wrote: > Thank you for that clarification. > >> The framework decides which Collector to use based upon the 'gc' >> attribute of a function: >> >> define void @f() gc "mygc" { >> ... >> } > > OK, so for instance if I wanted to be able to use the GC from a C > frontend (presumably by

Thank you so much for your help! I now have a much clearer idea of how to proceed. :-) This just keeps getting more interesting. - Simon 2008/7/26 Gordon Henriksen <gordonhenriksen at me.com>: > On Jul 26, 2008, at 12:14, Simon Ask Ulsnes wrote: > > 2008/7/26 Gordon Henriksen <gordonhenriksen at me.com>: > > I'm not sure the purpose of doing so—llvm::Collector

On Jul 26, 2008, at 12:14, Simon Ask Ulsnes wrote: > 2008/7/26 Gordon Henriksen <gordonhenriksen at me.com>: >> I'm not sure the purpose of doing so—llvm::Collector (poorly named; >> I'm open to suggestions) exists only in the compiler, not at >> runtime in the compiled program. You should need access to it at >> runtime no more than you might need

2008/7/26 Gordon Henriksen <gordonhenriksen at me.com>: > I'm not sure the purpose of doing so—llvm::Collector (poorly named; > I'm open to suggestions) exists only in the compiler, not at runtime > in the compiled program. You should need access to it at runtime no > more than you might need access to an instance of llvm::TargetMachine. Maybe I don't understand the

...this compile-time class was the place to implement their runtime GC heap. Of course, it doesn't even exist at runtime. Specifically, the renames are: Collector -> GCStrategy CollectorMetadata -> GCFunctionInfo CollectorModuleMetadata -> GCModuleInfo CollectorRegistry -> GCRegistry Function::getCollector -> getGC [setGC, hasGC, clearGC] Several accessors and nested types have also been renamed to be consistent. These changes should be obvious. Please let me know if you have any questions! Thanks, Gordon P.S. Sorry for the short notice; th...