Support Download-CI LLVM

[ZuseZ4]

Building LLVM from source takes a lot of resources, so we should add support for
download-ci-llvm in x.py
https://rustc-dev-guide.rust-lang.org/building/bootstrapping.html?highlight=download#what-is-a-sysroot
We discussed this previously in a weekly meeting, but without getting to a conclusion.
This is orthogonal to MSVC support.

cc @jedbrown @wsmoses

[wsmoses]

Can you explain the problem since I don't understand why this wouldn't work offhand?

[ZuseZ4]

Yes, right now Enzyme's cmake makes certain assumptions which fail for the LLVM which we would get when using download-ci-llvm. A first improvement would be supporting llvm-config. Valentin mentioned this would fail for cross-compilation, but better than nothing.
The alternative would be to ship more files with Rust's LLVM, but some people were not really excited by shipping extra files only for Enzyme: https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/distribute.20LLVM.20CMake.20modules.3F
EnzymeAD/Enzyme#1667 (reply in thread)

[wsmoses]

What assumptions are being made mistakenly here? From what I follow in the discussion it looks like Rust is not exporting the LLVM Cmake files, which presumably needs to be resolved in upstream rust.

Alternatively Enzyme now supports a secondary build system Bazel if CMake is undesirable.

Perhaps seeing the error logs would be helpful to understand the issue if you could past them?

[jedbrown]

The build fails (or finds a system libLLVM) when the CMake files are missing for Rust's libLLVM. There is some upstream resistance to bundling those files in all contexts in which libLLVM is distributed. I don't follow what all is going on in the 350 kB of CMake script distributed in $prefix/lib/cmake/llvm/, but it sounds like we may not be able to work around it being missing? We could go back to the Rust developers and ask again, but I think they're generally not wild about other users linking directly to their libLLVM.

[wsmoses]

So these files are how the build system learns where files are as well as various variables/functions/etc. Such as add_public_tablegen_target (https://github.com/EnzymeAD/Enzyme/blob/f7a46fd41562e13a622613f63b12fa67418213bf/enzyme/Enzyme/CMakeLists.txt#L31) which are used by us to generate the required C++ include files with derivative implementation.

So we do need the functionality in those files, not just the library directories.

You could probably copy these from some version of LLVM into a separate findLLVM.cmake script that adheres to the assumptions/conventions of rust with the corresponding path to the rust libraries.

But at that point it may just be easier to bundle the LLVM cmake files

[jedbrown]

Well, in standard mode, precompiled libLLVMEnzyme-17.so will be shipped in their binary distribution so the CMake files (and a C/C++ compiler for that matter) won't be needed. It is useful for anyone who wants to develop autodiff functionality since they'd like to be able to upgrade Enzyme without first needing to recompile libLLVM. We might be better off running our own CI to create weekly-ish builds that include CMake files, but not trying to change how upstream does it. If it's just the three people in this thread, we're probably accustomed to building libLLVM so this is not so urgent.

[ZuseZ4]

closing in favour of upstream discussion.