LngelKyo opened a new pull request, #20252: URL: https://github.com/apache/tvm/pull/20252
#19368 aligned `tir.round` to ties-to-even across LLVM, CUDA, NVPTX, ROCm, Hexagon, Metal, OpenCL, SPIR-V and WebGPU, and #20131 fixed the C host — but the shape of the original bug is still possible: **a new backend can implement `tirx.round` without ties-to-even and no test will notice**, because `test_round_ties_to_even` (tests/python/tirx-base/test_tir_intrin.py) is pinned to `target="llvm"`. The C host passed every test for four months for exactly this reason: its ties behaviour was never exercised, and the one test that covers it only ran on LLVM. **What this PR does** Parametrize `test_round_ties_to_even` over every backend that implements `tirx.round` — `llvm`, `c`, `cuda`, `rocm`, `metal`, `opencl`, `vulkan` — following the target-skipping convention of `test_codegen_loop_step` (`c` is always runnable, the rest gate on `tvm.testing.device_enabled`). The midpoint vector is the one #19368 added, reused verbatim. **Verification.** On a local build: reverting the C rule to its pre-#20131 ties-away-from-zero form makes `test_round_ties_to_even[c]` fail with the expected midpoint mismatches (`0.5 → 1.0 vs 0.0`, `2.5 → 3.0 vs 2.0`, `−0.5 → −1.0 vs −0.0`), while `[llvm]` still passes — i.e. the parametrized test now catches the class of bug that #20131 fixed. With the rule restored, `llvm` and `c` pass and the GPU targets skip cleanly on a CPU-only machine. **Second commit** is docs-only: it pins the floating-point-environment assumption from the #20131 discussion into `src/target/intrin_rule.cc` — nearbyint is ties-to-even under the default `FE_TONEAREST`; the CUDA/Metal/OpenCL rules share that assumption, while LLVM lowers to `llvm.roundeven`, which is environment-independent. Nothing in TVM's runtime sets the rounding mode, so `FE_TONEAREST` holds on every host we target. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
