llvm-project

317d1a15 - [LangRef] Adjust reduce.fmin/reduce.fmax behavior for sNaN (#196053)

[LangRef] Adjust reduce.fmin/reduce.fmax behavior for sNaN (#196053) The reduce.fmin/reduce.fmax intrinsics are designed as unordered reductions, just like all reductions that do not take a start value. However, if one of the elements is sNaN, then the reduction order matters. I *tried* to account for this when implementing the sNaN changes for minnum/maxnum in LangRef, but didn't correctly consider the consequences: It's not sufficient to just say that if one value is sNaN, either the result is NaN or its treated as qNaN. For example, if we reduce over `<sNaN, 0.0, 1.1>` then (picking the IEEE behavior for each maxnum): * maxnum(maxnum(sNaN, 0.0), 1.0) = maxnum(qNaN, 1.0) = 1.0 * maxnum(maxnum(sNaN, 1.0), 0.0) = maxnum(qNaN, 0.0) = 0.0 * maxnum(maxnum(0.0, 1.0), sNaN) = maxnum(1.0, sNaN) = qNaN So if any value is sNaN, even if the result is not a NaN, it may not actually be the maximum of the non-NaN values. As such, change the spec to simply say the reduction is performed non-deterministically in any order, and comment on the consequences of that.