[ANN] LLVM 15 is out!

Community
1

The OCaml bindings to LLVM 15 have been released on opam!

This is a milestone in work contracted by the OCaml Software Foundation to ensure the OCaml LLVM bindings remain up to date with both changes in OCaml and LLVM. First, I would like to thank @jjb for supervising me, and @Kit-ty-kate and @Kakadu on GitHub for their valuable help.

While previous versions of OCaml have supported naked pointers (pointers to outside the OCaml heap as OCaml values), OCaml 5’s new multicore runtime disallows naked pointers. Furthermore, OCaml 5 deprecated various runtime API functions. I had previously written ⚙ D136400 [llvm-ocaml] Migrate from naked pointers to prepare for OCaml 5 to adapt the LLVM bindings on the main branch to these changes, but LLVM 15 had already been released by then, with naked pointers in use. Therefore, I backported D136400 to LLVM 15 on my fork, and this fork is what is published on opam. Therefore, the version of LLVM 15 on opam is compatible with OCaml 5.

Furthermore, the LLVM IR has been migrating from pointers which carry the types of their pointees to untyped “opaque pointers.” As a result, many LLVM API functions have been deprecated and replaced. For example, build_call has been deprecated with the replacement being build_call2. I have added deprecation alerts to the relevant functions and added missing bindings to construct opaque pointers.

The changes between the upstream LLVM 15 branch and the fork published on opam can be viewed at Comparing llvm:release/15.x...alan-j-hu:aa44040b6096870d6bdecc7cc7c9e554f7b25a54 · llvm/llvm-project · GitHub.

Independently, @Kit-ty-kate had been working on building the LLVM bindings with Dune instead of the in-tree OCamlfind-based system at GitHub - kit-ty-kate/llvm-dune: The official LLVM OCaml binding but built using dune. Her repo has a Git submodule that points to my fork of LLVM, and her repo contains the Dune scaffolding that the LLVM 15 release on opam uses. This change of build systems may have implications for selecting between dynamic and static linking to LLVM:

  • Prior opam releases of LLVM use OCamlfind, which is supported via the in-tree META file. The package had a script that installed versions of the bindings that link statically or dynamically to LLVM (if each was available) and patched the META file to use the llvm.static predicate to choose between them.
  • The llvm.static predicate can be set using OCamlfind but cannot be set from Dune.
  • The LLVM 15 release uses Dune, which it supports by running a script that generates Dune files in the source tree. The script’s generated Dune files use the virtual library feature to define versions of the library that link statically or dynamically to LLVM (if each is available).
  • OCamlfind-based packages don’t understand the Dune virtual library feature and therefore cannot use the “default implementation” and must select the static or dynamic implementation explicitly.
  • @kit-ty-kate believes that the package builds faster and is easier to maintain with Dune.

Further context: Ask for suggestions for the next z3 package release - #4 by kit-ty-kate and Using output of `ocamlfind <params> -only-show` in a dune build.

In the process of preparing this release, @Kit-ty-kate and @Kakadu tested my changes on their personal projects and helped uncover issues.

Please let me know if you have any questions.

16 Likes
2

Thank you for dusting off the bindings !
I have some questions :

  • Do you plan on updating them to LLVM 16 ?

  • Until now, the documentation was available on an external website (llvm.moe.org). It’s not really easy to navigate and I’m not sure it is kept up-to-date. The OCaml website seem to have a nice new interface for documentation but it doesn’t seem available for llvm : llvm 15.0.7+nnp-2 (latest) · OCaml Package Any chance to get it working ?

  • Finally, how did you deal with the legacy pass manager vs the new one ?

3

llvm.moe was kept up-to-date by @whitequark back when she was the one maintaining the binding. In practice the binding never changed that much since LLVM 7 so it was mostly up-to-date until now. However this version adds a couple things to the API and LLVM 16 will change and remove some of the functions, so that won’t be true anymore.

My guess is that the service behind it uses Debian 11 to build the package, but llvm-15 is only available on Debian 12 (cc @sabine)

4

My assessment is that this is unlikely to build in the short term.

The service that builds the documentation needs to be developed further to enable more different build environments. This concerns other Linux environments as well as all the other Tier-1 OCaml targets (macOS, Windows, FreeBSD).

Thank you for bringing this up because it helps us highlight how this work is important. In the meantime, I opened an issue here: Building Docs for Packages When Depext is Unavailable · Issue #146 · ocurrent/ocaml-docs-ci · GitHub

1 Like
5

I’m happy to transfer llvm.moe and the ‘infrastructure’ (static site where I copy things sometimes) to someone who is willing to maintain it; @kit-ty-kate do you want it?

6

I already have too much on my plate so I would rather not, but maybe @alan ?

7

Actually, I have a better idea: I set everything up to use GH Pages instead and I merge pull requests from whoever adds a new version of the docs. Sounds good? I can keep paying for the domain, it’s not a huge burden.

3 Likes
8

That sounds good by me

9

Theoretically speaking, how far away we are from providing MLIR bindings for OCaml?

1 Like
10

MLIR bindings would be a separate effort and I don’t know that anything beyond some experience would carry over from the existing LLVM bindings. I don’t know if anyone is working on this. There is a C API, so at least the task would be comparable to the OCaml bindings of the LLVM-C api, as opposed to needing to bind the C++ api. There are ~650 exported types and functions, so it is not small, but not yet super-huge. If I were to need such bindings, I would start by trying camlidl to see if the interface is uniform enough to allow the bindings to be generated mostly automatically. If so, experimental and untested bindings might not take very long. Getting to the point of it being reasonably well-tested would be a significant amount of work.

2 Likes