[llvm] [CI] Switch to a single runtimes build (PR #131913)

[Aiden Grossman via llvm-commits]

boomanaiden154 wrote:

> Is there an understanding what caused such slowdowns? One reason I can see is diverting a chunk of resources towards BuiltKite-to-GitHub transition, but could there be more?

The resources aren't getting diverted. We're running both systems in parallel. Buldkite has the same number of resources as before.

> 10 minutes out of how much?

Typically 30, so approximately 30% of the build/test time.

> I can agree with that regarding C++03 build, but as C++20 modules are (slowly) adopted, Clang modules build becomes increasingly more relevant, because Clang modules shares a lot of code paths with C++20 modules.

They share code paths, sure. But they're a fairly atypical combination. I can understand wanting to test it in premerge CI, but we need to have balance we cannot test everything, and we want to provide results quickly. To me, anything that requires building a project in more than one configuration shifts the balance strongly towards exhaustive testing, which I do not think we should be doing in premerge CI.

> I don't follow. Even of runtimes can be built today via LLVM_ENABLE_PROJECTS, which I'm not sure about, the code you remove relies on LLVM_ENABLE_RUNTIMES.

The ability to build runtimes with `LLVM_ENABLE_PROJECTS` is going to be deprecated (see #124009). This means we have to move all the runtimes we currently test to the runtimes build. Trying to support multiple runtime build configurations with a bunch of projects that probably don't care about those features (libc, compiler-rt, etc.) adds complexity, although is doable.

It's hard to strike a balance against exhaustive testing and keeping premerge fast. If clang developers have evidence that this catches a significant number of issues, I think we can look at reenabling it just for builds of clang. With how things are setup right now though, touching MLIR, LLVM, Flang, or Clang will cause all of these runtimes to be rebuilt, which isn't the most tractable in terms of build scalability.

https://github.com/llvm/llvm-project/pull/131913