[Mlir-commits] [llvm] [mlir] [APFloat] Don't turn a Float8E8M0FNU NaN into an Inf on conversion (PR #214919)

[曾鈜寬 Tseng Hung Kuan]

Tim096 wrote:

Thanks for looking at it, @janr-bay.

@matthias-springer would you have time to take a look? The short version:

- `Float8E8M0FNU` is the only semantics with `precision == 1`, so its NaN has no payload bits. `IEEEFloat::convert` shifts that empty significand into the target, leaving the NaN exponent with an all-zero significand, which is the encoding of an Inf.
- `convert` returns `opOK` with `losesInfo == false` and `isNaN()` keeps returning true, so this only becomes visible once the bit pattern is stored. In MLIR that is folding `arith.extf` on an `f8E8M0FNU` constant, where the OCP MXFP spec uses NaN as the scale of an invalid block.
- The fix is 5 lines next to the existing `fltNanEncoding::NegativeZero` fix-up, which handles the analogous NaN-to-`-Inf` case. Only that one source format is affected.
- Tested exhaustively over all 256 `Float8E8M0FNU` values against f16, bf16, f32, f64 and f128. Reverting the `APFloat.cpp` hunk makes the new unit test fail. Premerge CI is green.

One thing I would like a second opinion on: I left `losesInfo` as `false`, on the grounds that the source had no payload to lose. Treating the rebuilt NaN as lossy would also be defensible.

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