search for: collectorregistri

This is a template that takes care of managing plugin registries. I wrote it because I got the distinct feeling I was needlessly reinventing the wheel as I wrote a collector registry. 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

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: Am I supposed to instantiate my collector

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

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 using llvm_gc_allocate?), do the C functions need this attribute as well? And if so, can this

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

Hi all, In order to support linking AsmWriter separately from CodeGen, the Collector class (a CodeGen component) had to be decoupled from the AsmWriter interface. This required moving the beginAssembly and endAssembly methods to a separate abstract base class. If you had overridden these methods, your class may compile successfully but fail at runtime with a message of the form: