[clang] [llvm] Disable compiling and testing Flang on Clang changes (PR #92740)

Mehdi Amini via llvm-commits llvm-commits at lists.llvm.org
Mon May 20 10:03:34 PDT 2024


================
@@ -68,7 +68,7 @@ function compute-projects-to-test() {
       done
     ;;
     clang)
-      for p in clang-tools-extra compiler-rt flang lldb cross-project-tests; do
+      for p in clang-tools-extra compiler-rt lldb cross-project-tests; do
----------------
joker-eph wrote:

> Can you point out where this is encoded in this file? I only see Flang specified as a dependency of MLIR (not the other way round).

This is what I mean: Flang is always test for all changes in MLIR, even when such change affect a subset of MLIR that Flang does not use. This is the analog situation with Clang where a change to Clang always trigger testing flang even when it touches the subset of Clang that can't impact Flang.

> This approach is very expensive in practice. 

"Pre-merge testing is very expensive", yes...
What can we say about changes to LLVM which triggers testing the entire monorepo (almost), even though a change to the PowerPC backend **cannot** possible fail a test in MLIR for example (unless you run the CI on a power-PC machine)? (and likely similarly can't fail a LLDB test, I'm not sure).

But what are you arguing about here exactly? What is the core principle to use for testing the monorepo in a premerge context?
Are you saying that there should be no dependency between the top-level projects at all for example?

> I think this trivializes the current situation -- this is not "for the sake of a problem on windows", this is for the sake of the entire community that has been raising concerns with how unusable precommit CI has been for the past ~six months.


Sorry but you're again equating what I believe is a "windows problem" with "precommit CI" as a whole: 
1) claim of "unstable" are dubious to me: this is vague and unspecified
2) The ci is very backed-up, and that's because Windows testing is slow. Someone proposed to remove windows from the pre-commit testing but I think you were the one opposing this. 

What I see on PRs on my side is that it always ends up with the Linux build completing while Windows waits for an agent for hours. Hence "it's a windows problem".

So we're gonna be on the opposite side of who is trivializing he situation here!

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


More information about the llvm-commits mailing list