[llvm-commits] GC patches again

[Chris Lattner]

>> 2. Adding a -gc option to llc isn't what we really want.
>
> Right. I think it should be attached to the module (perhaps via the
> [sub-]target) so that the module is self-contained and magic command-
> line options are not needed.
>
> I toyed with the idea of attaching it to the function to allow linking
> modules with differing collectors. That might be a good idea.
>
> I do not think attaching it to the operations (ala EH) is wise;
> different collectors could have differing requirements of the stack
> layout. This precludes inlining Java into Ocaml, but the null
> collector doesn't count.

Okay, I don't think we'll be able to inline code effectively that  
uses two different collectors.  My brain hurts thinking about what to  
do if you get to a stop point valid in one collector but not the  
other etc.

>> Ideally, the code generator would generate gc info for a function
>> iff there is a gcroot in it.  This would allow the codegen to emit
>> GC code code that obviously uses it.  Is there any case where the
>> codegen has to do something for a function with no gcroots (or
>> declared safepoints
>> etc) in it?
>
> There is.
>
> - Ocaml needs to know the frame size at each safe point, regardless of
> whether there are roots in the function.
>
> - Sun's JVM does something analogous in that it enforces a stack
> layout so that its stack walker (and HotSpot) can work.
>
> So, generally, safe points are safe points regardless of whether the
> function has roots.

Another option is to mark each function that requires GC info with an  
attribute.  The attribute could encode the GC model to use as well.   
This is basically the front-end telling the codegen what to do, which  
is better than relying on a magic command line optn.

> -- Gordon
> sent from my iPhone

nice ;-)

-Chris