[LLVMdev] ocaml+llvm

[Gordon Henriksen]

On 2007-08-13, at 16:33, Chris Lattner wrote:

>> The biggest problem is a data structure called the frame table, a  
>> simple structure for which LLVM seems ill-prepared. For each call  
>> site in the program, ocaml emits an entry into this table:
>>
>>     key   : the return address of the call site
>>     value : the stack offset of every variable live after return
>>
>> The garbage collector uses this when walking the stack to find  
>> live objects.
>
> I don't think you want to try to have the LLVM code generator build  
> this table.
>
> 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. Changing  
these structures breaks binary compatibility (including C interop).

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

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

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

Ñ Gordon


[1] Yes, this is a downside. :) Possibly the dominant one, since this  
is a weekend project.

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

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