Where is pass-manager gone in LLVM 15?

[kit-ty-kate]

cc @alan-j-hu

When I tried to build my personal project using LLVM 15 i noticed that anything pass-manager related was gone, but no indication of what to use instead.

https://github.com/llvm/llvm-project/commit/e0efe46b33068f2e651e850cdc3ede0306f1853c

What should I use instead?

[alan-j-hu]

The old pass manager was deprecated, but the new pass manager bindings have not been written yet. Writing the bindings for the new pass manager was one of the tasks I was assigned to do by @jberdine and the OCaml Software Foundation. I have a branch of the latest LLVM that has some bindings in progress (https://github.com/alan-j-hu/llvm-project/tree/ocaml-npm), but the API design has not completely been worked out yet. @jberdine told me that he "would be out of touch until August," and today is July 31, so hopefully he will be available soon.

From what I can tell glancing at the LLVM 15 branch, it still has the old pass manager bindings. Was there anything you need that was removed in the LLVM 15 release that I have missed?

[kit-ty-kate]

Yes i need Llvm_passmgr_builder.populate_lto_pass_manager

[alan-j-hu]

Okay, I see. It was removed in this commit: https://github.com/llvm/llvm-project/commit/e0736e742922a26506db46151f8491873b8c458c, which was a "follow-up" to https://reviews.llvm.org/D123882. I can't immediately tell what the replacement is supposed to be, maybe I can ask about this on the LLVM forums.

[alan-j-hu]

I got the answer from https://discourse.llvm.org/t/replacement-for-lto-of-the-legacy-pass-manager-in-llvm-15/72439 that you should pass the "lto<O2>" string as an argument to LLVMRunPasses. LLVMRunPasses is part of the C bindings for the new pass manager, and equivalent OCaml bindings do not exist yet. This is what I was working on with @jberdine.

Do you want to hold off on releasing the LLVM 15 bindings on OPAM until I get an API design settled and merged into LLVM main? Or should LLVM 15 be released without the new pass manager bindings, and then release a new minor version that backports the bindings later?

The LLVM 17 branch has already been cut from main. If I have to keep patches that backport the new pass manager, my forks of LLVM will become more divergent from the upstream branches. In the end, I might up maintaining a de-facto official permanent fork of the LLVM bindings that pulls from upstream, but introduces a lot of patches to ease migrations. I feel like I would like an opinion from @jberdine on the implications of this.

[kit-ty-kate]

Do you want to hold off on releasing the LLVM 15 bindings

no no, don't worry. I was already against backporting the nnp patches to LLVM 15 (i personally think backporting/patching as a general concept is something that we have to do only in extreme cases otherwise it introduces more harm than good) but since you were hired to do that i didn't think it fair to block on this.

As you can see in https://github.com/kit-ty-kate/labrys/pull/11/files#diff-abae1a57cddad2604019bfa1ea3db4a8f8fc69466f415b2544a033419056b8beR93 this is the only thing missing and it's not a big deal for me personally if it's not there (though it will be truly missed 🫡). I'm happy waiting for LLVM 17 or whichever.

[terencode]

What's the status with the llvm17 version on opam? I'm missing llvm.scalar_opts, llvm.ipo and llvm.passmgr_builder.

[jberdine]

Since the old pass manager is gone in upstream llvm, I think you need to switch to calling run_passes with the string corresponding to the old passes you need.

[terencode]

Since the old pass manager is gone in upstream llvm, I think you need to switch to calling run_passes with the string corresponding to the old passes you need.

This interface doesn't seem to be present with the current 17.0.6 opam release.