[PATCH] [review request] OCaml bindings: build stub OCaml libraries for all configured targets

Peter Zotov whitequark at whitequark.org
Sat Oct 12 11:38:39 PDT 2013


Hi sylvestre.ledru,

This is a complex change and I'm not sure I made it correctly.

In order for the TargetMachine interface to be useful, it is necessary to populate the TargetRegistry with targets, assembly printers and so on. OCaml bindings rely on static libraries for linking to the LLVM code. Linking a single OCaml executable with X86 codegen and its dependencies takes about 6 seconds; adding ARM makes it twice as long. I think it is therefore unacceptable to just always link in all targets.

So, a good idea would be to make an OCaml package per architecture, i.e. llvm.ARM, llvm.X86 and so on. However, this raises several questions.

1. Does it make sense to split them further? E.g. llvm.X86.asm_parser, .target, ... ? I think not: one would always want to link in the codegen, and other components contribute insignificantly to size/link time anyway.

2. How to integrate with the build system? The current Makefile.ocaml cannot handle more than one library per Makefile, and in general the build system doesn't like generated source files. Also, there is no simple way to detect if the current target features optional components such as AsmParser, AsmPrinter, etc. I've attempted to autogenerate the stub libraries, but it may actually be simpler to write one per backend explicitly. I don't like both solutions though.

http://llvm-reviews.chandlerc.com/D1927

Files:
  bindings/ocaml/Makefile
  bindings/ocaml/backends/META.llvm_backend.in
  bindings/ocaml/backends/Makefile
  bindings/ocaml/backends/Makefile.common
  bindings/ocaml/backends/backend_ocaml.c
  bindings/ocaml/backends/llvm_backend.ml.in
  bindings/ocaml/backends/llvm_backend.mli.in
-------------- next part --------------
A non-text attachment was scrubbed...
Name: D1927.1.patch
Type: text/x-patch
Size: 9102 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131012/f73f42f7/attachment.bin>


More information about the llvm-commits mailing list