[LLVMdev] ocaml+llvm

[Chris Lattner]

On Mon, 13 Aug 2007, Gordon Henriksen wrote:
>>  The table is a contract between the specific codegen you're using and the 
>>  GC runtime you're using.  This contract is specific to the current ocaml 
>>  code generator.
>
> Ocaml is compiled statically; this isn't an ephemeral link from JIT to 
> runtime as might be the case for a Java or Perl program.

JITing vs native codegen is orthogonal to this problem.

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

>>  In the LLVM world, you should use the first-class support we already have 
>>  for accurate GC: http://llvm.org/docs/GarbageCollection.html
>> 
>>  Based on this, you annotate the variables with llvm.gcroot intrinsics,
>
> I'm totally on board with that. The llvm.gc* intrinsics are well-designed as 
> hooks for runtime-specific code generation. I just need to custom lower 
> llvm.gcroot, too.

Yep.

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

> Here are the respective negatives I perceive:
>
> Ditch the frame table and write a new runtime:
> - no need to write any interesting LLVM code! [1]
> - breaks binary compatibility (including C interop)
> - have to write new runtime; llvm's GC is a strawman
> - makes an ugly patch, which makes for licensing problems [2]
>
> Tread lightly:
> - generated .bc is incompatible with llc due to runtime-specific GC codegen

I totally agree.  Given that there is no real client for the LLVM GC 
hooks, you are free to break or redesign what we already have: go crazy! 
:)

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

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/