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>
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 codegenI 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/
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>