What happened?
Expected behavior
For ReduceMax([[NaN, 1.0], [2.0, NaN]], axis=1):
- Row 0
[NaN, 1.0]: NaN is present → result should be NaN (per ORT)
- Row 1
[2.0, NaN]: non-NaN value 2.0 should dominate → result should be 2.0 (per ORT)
Expected: [NaN, 2.0]
Actual behavior
IREE returns [NaN, NaN] — NaN infects row 1 even though it has a valid non-NaN maximum.
Input:
[[nan 1.]
[ 2. nan]]
ReduceMax(axis=1):
ORT: [nan 2.]
IREE: [nan nan]
ReduceMin(axis=1):
ORT: [nan 2.]
IREE: [nan nan]
Root cause
The linalg reduction lowering uses arith.maximumf / arith.minimumf with IEEE 754 NaN-propagation semantics (NaN always propagates), whereas ORT uses a semantics where the valid non-NaN value wins over NaN when NaN is not the only element.
Interestingly, TVM has the opposite bug: TVM under-propagates NaN (ReduceMax([NaN, 1.0]) → 1.0), using fmax semantics where NaN is treated as missing. Both diverge from ORT, but in opposite directions.
Note
While the ONNX spec is not fully normative on NaN behavior in reductions, ONNX Runtime handles it consistently and this divergence can cause silent numerical differences when switching runtimes.
Steps to reproduce your issue
Reproduction
import numpy as np
import onnx
from onnx import helper, TensorProto
x = np.array([[np.nan, 1.0], [2.0, np.nan]], dtype=np.float32)
X = helper.make_tensor_value_info("X", TensorProto.FLOAT, [2, 2])
Y = helper.make_tensor_value_info("Y", TensorProto.FLOAT, [2])
node = helper.make_node("ReduceMax", ["X"], ["Y"], axes=[1], keepdims=0)
graph = helper.make_graph([node], "main", [X], [Y])
model = helper.make_model(graph, opset_imports=[helper.make_opsetid("", 13)])
model = onnx.shape_inference.infer_shapes(model)
# Run through IREE pipeline (see full reproducer script)
Full reproducer: iree_bug_018_reducemax_nan.py
What component(s) does this issue relate to?
No response
Version information
Environment
- iree-base-compiler: 3.12.0rc20260515
- iree-base-runtime: 3.12.0rc20260515
- Python: 3.11
- OS: Linux
Additional context
No response
What happened?
Expected behavior
For
ReduceMax([[NaN, 1.0], [2.0, NaN]], axis=1):[NaN, 1.0]: NaN is present → result should be NaN (per ORT)[2.0, NaN]: non-NaN value 2.0 should dominate → result should be 2.0 (per ORT)Expected:
[NaN, 2.0]Actual behavior
IREE returns
[NaN, NaN]— NaN infects row 1 even though it has a valid non-NaN maximum.Root cause
The linalg reduction lowering uses
arith.maximumf/arith.minimumfwith IEEE 754 NaN-propagation semantics (NaN always propagates), whereas ORT uses a semantics where the valid non-NaN value wins over NaN when NaN is not the only element.Interestingly, TVM has the opposite bug: TVM under-propagates NaN (
ReduceMax([NaN, 1.0]) → 1.0), usingfmaxsemantics where NaN is treated as missing. Both diverge from ORT, but in opposite directions.Note
While the ONNX spec is not fully normative on NaN behavior in reductions, ONNX Runtime handles it consistently and this divergence can cause silent numerical differences when switching runtimes.
Steps to reproduce your issue
Reproduction
Full reproducer:
iree_bug_018_reducemax_nan.pyWhat component(s) does this issue relate to?
No response
Version information
Environment
Additional context
No response