[swjng]

Problem

The ONNX Round operator specification requires ties-to-even (banker's) rounding:

"For cases where number is exactly halfway between two integers, it rounds to the nearest even integer."
— https://onnx.ai/onnx/operators/onnx__Round.html

However, the current TVM implementation produces ties-away-from-zero results on midpoint values:

Input	Expected (ties-to-even)	Actual (ties-away)
0.5	0.0	1.0
1.5	2.0	2.0
2.5	2.0	3.0
-0.5	0.0	-1.0
-2.5	-2.0	-3.0

This was reported in issue #18590.

Root Cause

The lowering chain for relax.op.round:

relax.op.round -> (LegalizeOps) -> topi.round() -> te.round -> tir.round -> llvm::round

llvm::round is defined as ties-away-from-zero (C99 round()), while llvm::nearbyint uses the IEEE 754 default rounding mode (ties-to-even).

Fix

python/tvm/topi/math.py: Switch topi.round() from te.round to te.nearbyint. This lowers to tir.nearbyint -> llvm::nearbyint, which respects IEEE 754 ties-to-even.

src/target/source/intrin_rule_webgpu.cc: Register tir.nearbyint for the WebGPU backend. WGSL round() is already ties-to-even per the WGSL spec, so tir.nearbyint -> round is the correct mapping.

tests/python/relax/test_frontend_onnx.py: Add test_round_ties_to_even() with explicit midpoint inputs to prevent regression.

Testing

python -m pytest tests/python/relax/test_frontend_onnx.py::test_round_ties_to_even -xvs
python -m pytest "tests/python/relax/test_frontend_onnx.py::test_unary[Round]" -xvs

Both pass. The new test compares TVM output against onnxruntime (which correctly implements ties-to-even) for inputs [0.5, 1.5, 2.5, -0.5, -1.5, -2.5].

Fixes #18590

[gemini-code-assist]

Code Review

This pull request updates the round operation in TVM TOPI to use ties-to-even (banker's rounding) by switching the underlying implementation to te.nearbyint, ensuring alignment with ONNX and IEEE 754 standards. It also adds the necessary intrinsic registration for WebGPU and a new test case to verify rounding behavior. Feedback indicates that the existing tirx.round registration on WebGPU is now inconsistent because it also maps to the ties-to-even round function, whereas it typically implies ties-away-from-zero; a follow-up is suggested to address this discrepancy.

[swjng]

As noted in the comment above, the same semantics is intentional. The actual pre-existing inconsistency runs in the opposite direction: LLVM/ROCm/Hexagon backends lower tirx.round to llvm::round (ties-away), contradicting the constant-folding behavior and op.h documentation. This affects LLVM, CUDA, ROCm, Hexagon, and potentially Metal/OpenCL backends.

Worth a follow-up issue to align all backends — tirx.round → llvm::nearbyint for LLVM-based targets would be the straightforward fix, though Metal/OpenCL need separate investigation.

[tlopex]

LGTM

[tlopex]

@swjng Thanks for the contribution! Could you send a follow-up PR to fix the problem you said?

[swjng]

@tlopex Yes, will make a follow-up