[Mlir-commits] [mlir] [mlir][arith] Fix arith maxnumf/minnumf folder (PR #114595)

[Clément Fournier]

oowekyala wrote:

@kuhar I updated the PR description

Just finishing this and I noticed another edge case for more tedium...

There are in fact 2 different implementations for IEEE754-2019's `maximumNumber` and `minimumNumber` in LLVM's `APFloat.h`: `maximumnum` and `maxnum` (and same for minimum). They are not documented as such, but they differ in that one returns a quiet NaN if both operands are NaN (even if one is signalling), and the other returns one operand (which could be signalling).

I'm not sure which of those to use. The IEEE spec says the following:

> - maximumNumber(x, y) is x if x > y, y if y > x, and the number if one operand is a number and the other is a NaN. For this operation, +0 compares greater than −0. If x = y and signs are the same it is either x or y. **If both operands are NaNs, a quiet NaN is returned, according to 6.2. If either operand is a signaling NaN, an invalid operation exception is signaled**, but unless both operands are NaNs, the signaling NaN is otherwise ignored and not converted to a quiet NaN as stated in 6.2 for other operations.

The spec of the arith ops does not specify anything regarding the handling of signalling NaNs (and in fact does not say either that it follows IEEE754-2019 spec). Should the part about "signalling an invalid operation exception" be implemented in arith? And if so, how? Should we fold to a poison value? Or just prevent folding in this case and let lower-level dialects handle this?

If we don't care about signalling NaNs then I think we should use the APFloat functions that produce quiet NaNs consistently.






https://github.com/llvm/llvm-project/pull/114595