[Mlir-commits] [mlir] [mlir][arith] Expand ops for F8E4M3FN and F8E5M2 type. (PR #216653)

Arun Thangamani llvmlistbot at llvm.org
Wed Aug 26 00:24:04 PDT 2026


================
@@ -830,13 +830,13 @@ struct F8E4M3FNExtFOpConverter : public OpRewritePattern<arith::ExtFOp> {
   }
 };
 
-/// Expand a TruncF to F8E4M3FN. The input magnitude is clamped to the F8E4M3FN
-/// maximum (448), scaled by 2^-8, and reduced to F16 (undoing the bias
-/// difference so the F16 value equals the magnitude times 2^-8). The low 7
-/// bits of the F16 encoding are then dropped with round-to-nearest-even to
-/// recover the 7 magnitude bits. Overflow into the NaN encoding is prevented
-/// by clamping, the sign is re-applied, and a NaN input maps to the F8E4M3FN
-/// NaN encoding.
+/// Expand a TruncF to F8E4M3FN. The magnitude is scaled by 2^-8 and reduced to
+/// F16 (undoing the bias difference so the F16 value equals the magnitude times
+/// 2^-8). The low 7 bits of the F16 encoding are then dropped with
+/// round-to-nearest-even to recover the 7 magnitude bits. F8E4M3FN has no
+/// infinity, so any input that overflows the maximum representable magnitude
+/// (448), as well as infinities and NaNs, maps to the F8E4M3FN NaN encoding to
+/// match the LLVM APFloat NanOnly overflow behavior.
----------------
arun-thmn wrote:

Yep, includes the `spec` reference in the comment.

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


More information about the Mlir-commits mailing list