[Mlir-commits] [mlir] [mlir][arith] Fold scaling_extf and scaling_truncf with constant operands (PR #215123)

[Hung Kuan Tseng]

Tim096 wrote:

**NaN special case removed**, head `b6b2ddb`. No test moved with it, which is
worth spelling out: widening an `f8E8M0FNU` NaN is lossless, so the general path
reaches the same NaN, and the finite-only result case (`f4E2M1FN`) was already
refused by `convertFloatValue` -- `arith.truncf %nan : f32 to f4E2M1FN` does not
fold either. What the special case actually bought was folding when widening
`in` is lossy, which no combination in the enumerated space hits. Re-ran the
sweeps after removing it and all three tables are unchanged:

| sweep | cases | folded | disagreements |
| :--- | ---: | ---: | ---: |
| `scaling_extf` f4E2M1FN x f8E8M0FNU -> f16 | 4096 | 656 | 0 |
| `scaling_extf` f4E2M1FN x f8E8M0FNU -> f32 | 4096 | 4096 | 0 |
| `scaling_truncf` f16 x f8E8M0FNU -> f4E2M1FN | 16777216 | 33390 | 0 |

**On folding any scale type**: I would rather do that as a follow-up, because
"matches what `--arith-expand=include-f8e8m0` does" is exactly the thing that is
still open. Today that pass extracts the exponent, so matching it means the
folder rounds the scale toward zero rather than to nearest -- which is the
decision in #215295, where you have just proposed carrying the mode in the IR
instead. And a wide scale can be negative or zero, where the expansion drops the
sign and reads `0x00` back as `0.0`; #216056 makes `APFloat::convert` report
both, and the folder needs that in place before it can safely convert a scale
itself.

So the order I would suggest is: land this restricted to `f8E8M0FNU`, settle
#215295, then lift the restriction with the rounding mode it decides on -- with
a sweep over all 65536 `f16` scales against the expansion. Happy to hold this PR
instead if you would rather see it in one piece.


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