[LLVMdev] ocaml+llvm

[Chris Lattner]

On Aug 14, 2007, at 3:24 AM, Gordon Henriksen wrote:
> On Aug 14, 2007, at 00:23, Chris Lattner wrote:
>> On Mon, 13 Aug 2007, Gordon Henriksen wrote:
>>> Changing these structures breaks binary compatibility (including  
>>> C interop).
>> If that is so, and if there is no way around this, then it makes  
>> sense to develop some compatibility mode.  How does native C code  
>> generate these tables?
>
> I might've conflated two related points. The frametable isn't  
> really at issue with respect to C interop. Rather, the decision to  
> get into the runtime business is.

Ok.

> To be specific, C interop doesn't generate frame table entries. It  
> anchors roots by explicitly registering/unregistering root pads  
> with the runtime. Very similar to the paper you cited, although not  
> a stack.

Ok, that seems easy to support. LLVM doesn't get in the runtime  
business either, the code generators just provide an opaque mechanism  
to walk pointers in the stack.  The GC runtime library discussed on  
the accurate GC page is nice (if it existed ;-) but optional.

> C interop does (from macros) use runtime information directly  
> derived from the data/text bracketing symbols I also mentioned.

Ok.

>>>>  and then walk the stack with the llvm_cg_walk_gcroots function.  
>>>> Note that  these are not well tested and probably have holes in  
>>>> them, but these are  the interfaces we want to use :)
>>>
>>> But here I have to disagree. Quite by design, LLVM lacks an  
>>> existing runtime to leverage: LLVM  CLR. In light of that, it is  
>>> difficult to justify ignoring a mature runtime that does exist in  
>>> order to avoid building a simple data structure.
>>
>> Sure.  Given a lack of current implementation, if the ocaml  
>> implementation would work and meet our needs, I have no problem  
>> with adopting/stealing it :)
>
> I'm not sure you want to incorporate ocaml's runtime per se; its  
> object model is very unique. :) How do you envision LLVM GC support  
> going?

No idea - I know little about the ocaml GC.  I assumed it was generic  
enough to be reused in other contexts.  If not, then disregard my  
comments.

> My thinking was to merely extend LLVM to be a less "uncooperative  
> environment" for GC (as the paper you referenced put it), while  
> maintaining neutrality to the runtime and object model.

Yep, sounds good.

> The two major problems I had really boil down to identifying GC  
> points in machine code and statically identifying live roots at  
> those GC points, both problems common to many collection  
> techniques. Looking at the problem from that perspective makes the  
> problem much more tractable, actually…

Yep.

>>> [2] ocaml is licensed under the QPL [Trolltech/KDE], which has an  
>>> onerous distribution clause which prohibits forks. My current  
>>> work leaves the existing code generator in place, touching only a  
>>> few files to integrate LLVM code generation as a runtime option;  
>>> this improves the possibility that a patch would be accepted, and  
>>> otherwise makes patch maintenance manageable.
>>
>> We can work around this on our end going forward.
>
> How so?

If it becomes important, we can re-implement pieces that are needed.

>> What this means in the short term is that we can't accept any  
>> Ocaml-project code into LLVM. This does not prevent the ocaml  
>> people from using LLVM code though.
>
> Exactly. ocaml is written in itself, so there's little likelihood  
> of that becoming a problem. :)

:)

-Chris