| commit | 16e4346b323e2138bed7a9af267be8f164c8bc3d | [log] [tgz] |
|---|---|---|
| author | bjacob <benoitjacob@google.com> | Tue Nov 14 10:58:09 2023 -0500 |
| committer | GitHub <noreply@github.com> | Tue Nov 14 10:58:09 2023 -0500 |
| tree | 10e29ff4ca6604b4bcf79f0ba06ab1ac06e37f93 | |
| parent | ef0f1a405783c9cf673487a61fda8fca8e83e8c1 [diff] |
ukernel test improvements (#15542)
* Consistently compare with/without skipping of intermediate roundings.
A catch is that the ukernel may fall back to a generic code path (and
that fallback is consistently exercised by the test, even when a
non-fallback path is also available and tested). And generic code paths
("tile functions") never skipped intermediate roundings, even if allowed
to by the flag. This caused complicated test code retrying again on
error. This PR simply adds the skipping-intermediate-roundings generic
tile functions, so the test code is simpler, and concretely I just
needed that for #15543 as I'm adding bf16-accumulator tile functions
that are skipping intermediate roundings.
* I had to also update `iree-e2e-matmul-test` to switch to skipping
intermediate roundings. Unlike the ukernels' own tests, which really
must test both flavors, in `iree-e2e-matmul-test` we are e2e testing
what the compiler produces, and that is skippig intermediate roundings
at least by default, and while that could be overridden with
`--iree-llvmcpu-skip-intermediate-roundings=false`, we don't currently
test that in e2e matmul tests.
* Generate better random test input values. Some were too large - when
we generate random bfloat16 to accumulate into bfloat16, they better be
very small as we don't want to grow accumulators to the point where they
would start rounding. It's OK, because bfloat16 kernels use bfloat16
arithmetic instructions, not bit hacks, so correctness is sufficiently
tested on very small values. Conversely, for int8/int16 test input
values, we were generating a very narrow range and that was potentially
missing important coverage as some of our int kernels are starting to do
evil bit hacks (#15525).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.