Last chance to get anything into llvm-c and ocaml bindings

I've pretty much finished exposing all I wanted to llvm-c and the
ocaml bindings for the soon to be released 2.7. Does anyone need any
other functions exposed before the code freeze on the 7th?

Erick Tryzelaar <erick.tryzelaar <at> gmail.com> writes:

I've pretty much finished exposing all I wanted to llvm-c and the
ocaml bindings for the soon to be released 2.7. Does anyone need any
other functions exposed before the code freeze on the 7th?

Hi Erick,

Can you make the following functions available in llvm-c.

createStandardFunctionPasses
createStandardModulePasses
createStandardLTOPasses

Thanks in advance, George

Oh hey... I remember now. There is one thing I probably won't get around to doing myself until after the code freeze.

  (* Llvm_bitwriter *)
  val output_bitcode: out_channel -> Llvm.llmodule -> unit

It would, of course, be awesome if you could get that into the 2.7 train.

Committed in r97858.

This is a little tricky, so I need some advice from the community.
First off, I'm not sure where it's appropriate to put these. For
llvm-c, most files live in a header named after the library that
includes the functions, and we don't have a corresponding place for
these functions. Perhaps they could go in a
llvm-c/Transforms/StandardPasses.h?

Second, createStandardModulePasses accepts an inlining pass an an
argument, but llvm-c doesn't expose a way to directly create any
passes. So, should I just not expose that argument, or should I add:

LLVMPassRef
LLVMCreateFunctionInliningPass
LLVMCreateAlwaysInlinerPass
LLVMCreatePartialInliningPass

But that seems silly just to expose those passes this way without all
the other passes and related functions. Does anyone have a better
suggestion?

Hi Erick,

Thanks for your timely reply.

For my use case and for a starting point I suggest to expose only
optimisation levels and boolean flags.

Cheers, George