| commit | f66d7f2acfba9f9e5e1e5d19f49da54a3bf4228a | [log] [tgz] |
|---|---|---|
| author | Benoit Jacob <jacob.benoit.1@gmail.com> | Fri Mar 01 23:13:33 2024 -0500 |
| committer | GitHub <noreply@github.com> | Sat Mar 02 04:13:33 2024 +0000 |
| tree | e681159e30ad734dd5642338ca5288272bffb58a | |
| parent | 5218ef2de07b21ed4284024c74cf947ed95c11a5 [diff] |
Fix enablement of mmt4d ukernel test cases based on ISA code paths built (#16637) This fixes `build_test_all_windows` CI and adds CI configuration to trigger it on all ukernel code changes going forward. There is an unresolved mystery as to what exactly went wrong on `build_test_all_windows` CI job, as its MSVC compiler failed the `check_cxx_compile_flags` for `/arch:AVX2` while the exact same MSVC version succeeded in the `build_test_runtime_windows` CI job. But regardless, there was something not well thought out in how I did the testcase enablement. I had added a global constant bool indicating whether we had linked architecture-specific code, but that was only per-architecture, not accounting for the fact that, depending on `check_cxx_compile_flags`, some sub-architecture code paths could be individually disabled. This new PR redoes that: the global constant bools are dropped, and instead, the problem is tackled differently in `mmt4d_test` vs `mmt4d_benchmark`: * In `mmt4d_test`, as we really want to avoid testcases silently testing nothing, we keep running *without fallback*, but we now condition testcases on `IREE_UK_BUILD_*` cmake-defined variables. * In `mmt4d_benchmark`, we just enable the fallback, so in the worst case if a code path is disabled, the outcome is a poor benchmark result. `mmt4d_benchmark` doesn't need to catch enablement, that's already done by `mmt4d_test`.
IREE (Intermediate Representation Execution Environment, pronounced as “eerie”) is an MLIR-based end-to-end compiler and runtime that lowers Machine Learning (ML) models to a unified IR that scales up to meet the needs of the datacenter and down to satisfy the constraints and special considerations of mobile and edge deployments.
See our website for project details, user guides, and instructions on building from source.
IREE is still in its early phase. We have settled down on the overarching infrastructure and are actively improving various software components as well as project logistics. It is still quite far from ready for everyday use and is made available without any support at the moment. With that said, we welcome any kind of feedback on any communication channels!
See our website for more information.
IREE is licensed under the terms of the Apache 2.0 License with LLVM Exceptions. See LICENSE for more information.