tree b801033ec574ba18caa8e894a52b950639f63d81
parent a9e91ecb68b23241349acfbb2ede00afa4c107b7
author Ege Beysel <beyselege@gmail.com> 1781022650 +0200
committer GitHub <noreply@github.com> 1781022650 +0200
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsFcBAABCAAQBQJqKD+6CRC1aQ7uu5UhlAAAEpwQAB8iKNG0DnCPFEEkLlTzsRcu
 NJvMvjWPED3yq3rhTRCXm9Bil8BkUvCayzNwxpmyVyQNX/bAE+MJ5vJ06WMP4UMr
 A34d/QPzuECCOUjTMUwiwa/ZgT8seIqUqbw2NDzu6uY2NT5jJu9XV6zpu+yDWlIW
 y5y6wifjXcUcwGSztFVqB95Ey7eNIUS9m6GOzSGfdc+DsR9FDcNX1NJe/stKbgvS
 MUCSTii7rzKxZ2wPQbDkpj8D/jouJ3TqJu0aw6lPfXMHLNUJjL7rYUMFJ7Gvq4GV
 8y7XKzt49ERCdH/TGFy3wszKe4T43V89Gayg7dYsaFzpE+199FEWkvEi14ePX10D
 8A+qsF6jkJ1ND52Yqmek5vK7C0j0KukJgZoU17XmnygHvMWjeLZnQ/h7OKbzDazh
 VuFoouWqT9KoNybzjBwuJ4CejFGNTFUI1M6EMGYLxs1l1a1AxXBYdKidueS1jQVe
 6GJlcnAnDX8YVxqDkv96yjPsJa4SQqbPT5jfLt0IsJ3tvOUQcpKPZEK1xZagZRb6
 UGaA2F5hG7FV9fB0MLVZkanZT/dW421HTLkjvSJY378n0Ba7dRFaT7yzHUA4CQox
 QodgRWHO4qWCz7ll4ZPt5BELK5MWyjv0GV2WMKNlNTNe+OI28w4hrVuV8CT3YCFz
 GiTtrjW0dJNkgvS0T0di
 =DIFX
 -----END PGP SIGNATURE-----
 

fix(CI): long-running emulated rv64 matmul integration tests (#24593)

The RISCV-64 e2e matmul integration tests without the ukernels are very
long-running under QEMU emulation, and were causing timeouts in CI. This
PR disables the generic (non-uk) vectorization path for those tests
until we properly support codegen.

(Claude-generated summary)

## Summary

The RISC-V 64 e2e matmul integration tests that run **without ukernels**
(`--iree-opt-data-tiling --iree-llvmcpu-enable-ukernels=none`) are
extremely
slow under QEMU and were timing out CI (60 s per-test limit). This PR
adds
`noriscv` to all non-ukernel `dt`/`experimental_dt` matmul variants,
since the
generic vectorization path for data-tiled matmul is not yet properly
supported
on RISC-V — only the ukernel path is validated there.

**Why it's slow:** with data-tiling on but ukernels off, the packed
`mmt4d` is
lowered through generic vectorization. For the wide `M0×N0` tile it
selects
(`N0 = VLEN/8`, `M0 = 7`), the widening multiply-accumulate has no
vector×scalar
form, so the inner loop rebuilds the LHS broadcast every K-step via a
storm of
`vsetvli` reconfigurations and `vrgather`/`vslideup` permutes — e.g. for
i8 at
VLEN=256, ~118 `vsetvli` + ~19 `vrgather` per dispatch, vs ~2 `vsetvli`
and no
gathers for the ukernel. QEMU emulates every vector instruction
element-by-element, and `vsetvli`/`vrgather`/`vslide` are among the
costliest to
emulate, so the full shape set runs for tens of seconds and trips the
timeout.
`dt_i8_i32` and `experimental_dt_i8_i32` hit it first; `dt_f32_f32` was
already
at ~52 s (one slow runner from flaking).

Failing CI run:
https://github.com/iree-org/iree/actions/runs/27192246864/job/80276315195

**Emulation vs. real hardware:** the timeout is largely a QEMU artifact.
On a
SpaceMiT X60 (VLEN=256, native), the heaviest shape (540×332×516) runs
in
milliseconds — but the generic path is still 3.5–6× slower than the
ukernel
path, confirming it exercises an unsupported/unoptimized path rather
than just
an emulator quirk:

| variant (540×332×516) | 1 thread | 8 threads | generic ÷ ukernel |
|---|---|---|---|
| i8 generic  | 123 ms | 37.9 ms | **6.1×** |
| i8 ukernel  | 20.3 ms | 6.15 ms | — |
| f32 generic | 108 ms | 29.1 ms | **3.5×** |
| f32 ukernel | 30.9 ms | 9.08 ms | — |

(The gap is specific to the wide-`M0` tile; narrow-M shapes pick `M0=1`,
emit
clean `vwmacc.vx`, and are ~1.3×.)


Assisted-by: Claude Code

---------

Signed-off-by: Ege Beysel <beyselege@gmail.com>