e2e matmul test improvements

[bjacob]

This PR is made of individual commits for review convenience and so we can drop anything that causes problems on CI.

• Add default shapes set, combining small and large.
  • The need to specify "small" or "large" is a real need in only a minority of cases. That's a difference from when these tests were first added.
• Enable dynamic sizes in large shapes, leaving only gpu_large_aligned out.
  • Who remembered that large shapes weren't tested as dynamic shapes, unlike small shapes... and unlike "gpu_large" shapes?!
• Rename gpu_large_aligned -> easy_large_static.
  • This is only needed in sketchy GPU codegen pipelines that can't deal with sizes that aren't multiples of some internal tile size.
• Fold gpu_large into large and tolerate fuzzy bf16 accumulators.
  • Retaining the evidently more curated set of shapes from "gpu_large". The larger sizes ran into new issues with the mostly artificial case of bf16 accumulators.
• Use default shapes and reenable sanitizers.
  • This simplifies the build, reduces the number of targets and increases coverage as "default" combines small and large shapes. And this reenables sanitizers that hard been disabled on large sizes due to timeouts. As tests at some point started verifying only a subset of result matrix elements, the timeouts should be avoided now.
• Enable default shapes for most rocm tests.
  • The motivation for this PR. The rest just bubbled up from there.
• Make large shapes more diverse (including odd and rectangular kinds of shapes).

[qedawkins]

Nice, that cmake file was a lot to navigate. I don't have much context about the cpu tests so maybe would be good to have a stamp from someone who does.

[bjacob]

@kuhar , can you review particularly the last commit here (changing the large test shapes, which were folded from the gpu_large shapes in another commit on this PR)? Based on @qedawkins 's comment, I changed the shapes a little to increase diversity.

[kuhar]

@kuhar , can you review particularly the last commit here (changing the large test shapes, which were folded from the gpu_large shapes in another commit on this PR)? Based on @qedawkins 's comment, I changed the shapes a little to increase diversity.

Looks fine to me, although these 'LARGE' cases are pretty small for modern GPUs. But I guess that's desired for in-repo tests.

[bjacob]

Looks fine to me, although these 'LARGE' cases are pretty small for modern GPUs. But I guess that's desired for in-repo tests.

Yes, there's a trade-off here. We could have an "XL" shapes set if at some point we think that some bugs are likely to be only caught with such shapes. We would just have to be careful to only use it on powerful targets such as GPU.

[kuhar]

@bjacob what's the accumulator type in bf16 tests? I'd expect it to be f32. bf16 is also fine but maybe not as the primary focus.

[bjacob]

@bjacob what's the accumulator type in bf16 tests? I'd expect it to be f32. bf16 is also fine but maybe not as the primary focus.

@kuhar: we have bf16 tests with f32 accumulators, and we also have bf16 tests with bf16 accumulator. It's always explicit in the CMakeLists / BUILD.bazel, e.g.: this has acc_type=bf16:

iree/tests/e2e/matmul/CMakeLists.txt

Line 486 in 5270093

"--acc_type=bf16"

The precision issues with large K sizes, which the commits in this PR address by relaxing tolerance, are of course only with bf16 accumulator. See how they are under case IREE_TEST_UTILS_VALUE_TYPE_BF16:, where the switch statement is on the result i.e. accumulator type.

Yes, f32 accumulator is what matters in practice. bf16 accumulator is something that we've supported in the CPU codegen mostly for completeness, so we also test it.

[ScottTodd]

Ah, this is starting to diverge from https://github.com/iree-org/iree-test-suites/tree/main/linalg_ops/matmul

I was hoping we could land iree-org/iree-test-suites#22 and switch from in-tree testing to using the test suite repo going forward, but that's been stalled. I can't devote much more time to that myself beyond the initial setup and prototyping (e.g. #18291)