Build and cache llvm

[makslevental]

This PR splits up build only in CI into two steps

1. Build LLVM
2. Build iree

Why do this if it only affects CI? Because now we can also cache/save/upload the LLVM distro for each successful build thereby giving everyone (not just CI) a distro of LLVM they can use to build iree locally. This cuts down the number of files you have to compile by like 60% (from 7500 -> 2900).

In case you didn't know, the CI artifacts are at the bottom of the summary page for any given run:

EDIT: in fact we actually need this for HSA (because ROCR requires an up-to-date Clang)¹.

EDIT2: This PR now also adds powershell scripts for building on windows

Footnotes

1. https://github.com/nod-ai/ROCR-Runtime/blob/amd-staging/runtime/hsa-runtime/core/runtime/blit_shaders/CMakeLists.txt#L71 ↩

[ScottTodd]

The extra build feels rather complicated to me, and it would be nice if iree-amd-aie didn't need to build LLVM itself in this way, but the approach you've taken looks good on the surface at least.

[ScottTodd]

Another option for this style of git operations is to use a script like https://github.com/iree-org/iree/blob/main/build_tools/scripts/git/update_runtime_submodules.sh. Sample usage here: https://github.com/iree-org/iree/blob/45132f5b1f1697e1f4d3450f0d6371c2ec49700a/.github/workflows/ci.yml#L209-L213. That does require checking out the repo with the script (without submodules) though.

With such a script, developers and workflows can share the same steps without copy/pasting all this.

[makslevental]

in general i'm not a fan of hiding stuff in scripts that get used in CI ymls - at least until github let's you jump to those scripts like it does for names in cpp. the exception (at least for iree-amd-aie) being cmake configure/build, which we do put into a script.

here in particular, this incantation isn't useful for devs because it's overly complex because it needs to work for forks (which i guess you well know from that example repo you showed me).

[ScottTodd]

👀
Is 114 a line number, pointing here: https://github.com/iree-org/iree/blob/45132f5b1f1697e1f4d3450f0d6371c2ec49700a/compiler/src/iree/compiler/API/CMakeLists.txt#L114? At a minimum it would be nice to make that more stable and not reliant on the file remaining unchanged.

I haven't noticed that "target_compile_definitions may only set INTERFACE properties on IMPORTED" error/warning upstream. Seems reasonable enough to patch it if it is causing issues downstream.

[makslevental]

yea that's the line - i'm guessing no one ever exercises the combo of "windows" + "byo llvm".

[ScottTodd]

FYI CMake 3.29+ has access to -DCMAKE_LINKER_TYPE=LLD: https://cmake.org/cmake/help/latest/variable/CMAKE_LINKER_TYPE.html

(We plan on bumping the CMake minimum in IREE and replacing -DIREE_ENABLE_LLD=ON with that official option)

[makslevental]

The extra build feels rather complicated to me, and it would be nice if iree-amd-aie didn't need to build LLVM itself in this way

yea i mean this is what we discussed on slack earlier this week - i would love to be able to either

1. build iree distro
2. build iree-amd-aie using iree distro
3. load iree-amd-aie as a plugin into iree-opt and iree-run-module

or

1. build iree distro
2. build iree-amd-aie-opt, iree-amd-aie-run-module using iree distro

both paths would save us a lot of CI and dev. but it's spot time right (full rebuild once every ~2 weeks when we bump iree if you're not sloppy and the bump is major). it mostly impacts new comers/explorers/tire kickers which i do care about but not so much that i'm gonna implement a plugin system for IREE lol. amortized it's not a lot of time so for now shaving 60% instead of 90% is good enough. revisit later 🤷