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 attribute be applied to functions in bitcode compiled by llvm-gcc, without modifications to the C compiler or the output bitcode? I.e., I use a custom driver program 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, > GordonIt helps a lot. Thank you for your time. :-) Simon
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 using llvm_gc_allocate?), do the C functions > need this attribute as well?Yes.> And if so, can this attribute be applied to functions in bitcode > compiled by llvm-gcc, without modifications to the C compiler or the > output bitcode? > I.e., I use a custom driver program 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).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 annotate the roots in the function. — Gordon
> 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 annotate the roots in the > function.Hm, it seems this will be more interesting than I had initially expected. I had assumed that the annotation took place at the IR level, so frontend compilers would not need to be modified. Would this be a viable alternative in the future? If not, do you think it would require very significant changes to the GCC frontend to make it annotate roots on the stack etc.? I'm thinking along the lines of a command-line option a la: llvm-gcc --emit-llvm -c myfile.c -o myfile.bc --garbage-collector=mygc This could be a fun project, if the GCC code is not too hard to modify like this. :-) – Simon
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 llvm_gc_collect (llvm_cg_walk_gcroots is provided by the Collector framework, right?) -- in those methods, how do I access the Collector object instantiated by LLVM? (It appears I do have to implement them myself, since otherwise there are unresolved symbols when I call them directly from my IR) - Simon