[mlir] [llvm] [CI] Add check-mlir-python to MLIR pre-merge checks (PR #72847)

[Louis Dionne via llvm-commits]

https://github.com/ldionne approved this pull request.

> > MLIR could define its own jobs that run appropriate checks and use appropriate dependencies.
> 
> Are you suggesting that we should split the monolithic config? That seems like a pretty bad idea for the mono-repo in terms of efficiencies: LLVM is pretty "heavy" to build and if I change MLIR that means right now running both MLIR tests and Flang tests. If Flang and MLIR have disjoint testing that means that we would build LLVM+MLIR twice (once for a MLIR job and once for the Flang job).

That's what I am suggesting. However, it doesn't mean we'd necessarily have to build everything twice, we could share stuff via artifacts or we could use ccache to reduce the amount of duplicate work we're actually doing. But I do think that the project would be better off with each sub-project defining the tests that make sense for them, yes.

> The monolithic config is just nicely setup to build just the set of needed projects once, and run the necessary tests.

The problem is that we don't run "the necessary tests". We run `check-<whatever>` and that's it -- for some projects that may be insufficient. For example this patch mentions that we need to also check `check-mlir-python`, but in the runtimes we have much larger needs like checking different configurations (exceptions enabled or not, etc). I suspect other projects have similar special needs which would not be met by the current monolithic config, and which wouldn't make sense to share across all LLVM projects. For instance it may not make sense to test `libc` with exceptions enabled and disabled, but that's definitely a requirement for e.g. libc++.

As mentioned here, there's also the need for potentially different tool versions being used by various projects, which is also not easy to accommodate in a monolithic world.

All in all, I have little stakes in this since libc++ already has its own setup that works for our needs. But I do believe that the other LLVM subprojects would see benefits in moving away from the monolithic setup and towards something where they control their CI configuration a bit more (obviously without having to go as far as to set up their own self-hosted builders, which should definitely be handled globally for all of LLVM).

As far as this change goes, I'm fine with it.

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