[CI] Disable Flang from pre-commit tests when Flang files are not touched on Windows Only

[joker-eph]

Flang triggers some OOM on Windows CI right now. This is disruptive to MLIR and LLVM changes that don't touch Flang, as such we disable building Flang on Windows only for these PR that don't touch flang. The testing on Linux is unchanged, and the post-merge Windows testing is still fully covering here.

[clementval]

Thanks Mehdi! That would be a nice solution to keep what seems to be stable and disable what is not.

[rengolin]

I don't know how that CI script works, but if that does what we wanted from #93485, then it should be fine to merge this and close the other.

[kiranchandramohan]

Thanks @joker-eph.
What would be a reasonable state for the Windows Flang builds to be re-enabled for LLVM and MLIR? Demonstration of One week or month without OOM in the flang patches (where the windows flang build and tests run)?

[rengolin]

What would be a reasonable state for the Windows Flang builds to be re-enabled for LLVM and MLIR? Demonstration of One week or month without OOM in the flang patches (where the windows flang build and tests run)?

Our new target policy states 3 months of stability, but that's an old policy for a different case on simpler times.

My take on this is that Flang is already an integral part of LLVM, but currently has unstable testing. I propose we follow the original buildbot testing convention to "move noisy bots to silent until they are deemed stable again" repeatedly, every time it gets noisy again. How long? It depends on what went wrong.

Let's say this time you fix the problem, wait a few weeks, then add to pre-commit CI again. If in a few months we start having problems again (reported, not fixed), I think it's perfectly reasonable for anyone (non-Flang developers) to re-land this same patch and open an issue to Flang owners to fix, restabilize, re-enable.

This should be a natural state of our pre-commit CI, not just for Flang or Windows, but for everything that causes grief to unrelated developers.

[joker-eph]

I don't have much to add to @rengolin here, I would start by looking at the "expensive" files in flang and try to split them maybe? Someone with MSVC 2019 could try to profile the build to find these files that are memory hungry maybe?