[LLVMdev] ocaml+llvm

[Gordon Henriksen]

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.

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.

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

>>>  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?

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.

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…

>> [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?

> 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. :)

— Gordon

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070814/9be2c498/attachment.html>