Most of the MLIR codebase does not need any LLVM targets to be configured in order to build and pass the
check-mlir test suite (i.e., -DLLVM_TARGETS_TO_BUILD="" should almost work). There are currently just 6 out of 418 test cases that rely on target info (list below), and
check-mlir would just pass if these weren’t run if no targets were configured. Given the significant build time that is saved when using an empty target list, would it be meaningful and easy to exclude these tests when
LLVM_TARGETS_TO_BUILD is empty?
Failing Tests (6):
MLIR :: mlir-cpu-runner/bare_ptr_call_conv.mlir
MLIR :: mlir-cpu-runner/linalg_integration_test.mlir
MLIR :: mlir-cpu-runner/sgemm_naive_codegen.mlir
MLIR :: mlir-cpu-runner/simple.mlir
MLIR :: mlir-cpu-runner/unranked_memref.mlir
MLIR :: mlir-cpu-runner/utils.mlir
I think it would make sense. We already have some mechanism to disable tests depending on mlir-cuda-runner and mlir-rocm-runner depending on cmake flags. We can do the same for CPU.
+1 from me. Ideally it would use the same disable mechanism that the CUDA/ROCM tests use.
As a side note, @aartbik started a set of integration tests that also depend on the CPU runner. They are disabled by default, but we should make sure they cannot be enabled if we don’t have the host target.
Thanks for pointing that out, @ftynse!
Just for completeness, the suite is enabled with -DMLIR_INCLUDE_INTEGRATION_TESTS=ON during setup. After that, you can run the suite with the target check-mlir-integration. Future contributions may go beyond just cpu-runner, but right now all suites depend on that.
Should be fixed in
ninja check-mlir goes from 1848 actions to 1650 when going from X86 to no target (2m05s on my machine).
And here is the list of the top 20 slow targets on my machine:
I think many of these files are just big, and thus take long. The file that I think has the highest compile time for its size in MLIR is
lib/Dialect/Linalg/Transforms/Loops.cpp - for just 746 lines, it takes nearly 11.5s to compile on a fast workstation (3.7 GHz Skylake-based Core i7) in release mode and with Clang 10.0! It’s probably due to the specific C++ patterns or templates used there - I was planning to post on it separately or file a bug/feature request. A time like that could be a drain on productivity. Files of similar size in MLIR build nearly 5x faster on the same system/config. Any compile time improvements will be welcome!
If you don’t yet, I also encourage you to try ccache: it helps a lot with iterative builds.
Yes, thanks. However,
ccache in such cases (like with
lib/Dialect/Linalg/Transforms/Loops.cpp) won’t help with each different update requiring the same amount of long time to build it.
It does not help with the part of the codebase you’re changing indeed.