[Mlir-commits] [mlir] [MLIR][Math] Fix math.ceil expansion to avoid undefined behavior on Inf/NaN (PR #170028)

[Benoit Jacob]

================
@@ -232,6 +232,37 @@ static LogicalResult convertCeilOp(math::CeilOp op, PatternRewriter &rewriter) {
   ImplicitLocOpBuilder b(op->getLoc(), rewriter);
   Value operand = op.getOperand();
   Type opType = operand.getType();
+
+  auto operandETy = getElementTypeOrSelf(opType);
+  unsigned bitWidth = operandETy.getIntOrFloatBitWidth();
+  unsigned mantissaWidth =
+      llvm::cast<FloatType>(operandETy).getFPMantissaWidth() - 1;
+  unsigned exponentWidth = bitWidth - mantissaWidth - 1;
+
+  Type iTy = rewriter.getIntegerType(bitWidth);
+  if (auto shapedTy = dyn_cast<ShapedType>(opType))
+    iTy = shapedTy.clone(iTy);
+
+  Value cMantissaWidth = createIntConst(op->getLoc(), iTy, mantissaWidth, b);
+  Value cBias =
+      createIntConst(op->getLoc(), iTy, (1ull << (exponentWidth - 1)) - 1, b);
----------------
bjacob wrote:

Exponent bias should be queried via `fltSemantics`, not computed like this.

Some floating-point types have non-standard bias, such as the FNUZ-suffixed fp8 types. `fltSemantics` should have that information.

I just looked up how it's done around APFloat.cpp.  `fltSemantics` does not have a `bias` field. Instead, it has a `minExponent` field, and bias is computed from it as follows (you could extract that into some kind of shared helper perhaps).

https://github.com/llvm/llvm-project/blob/fe754dff6d7ed3f7d69e5a97846d9320cb407977/llvm/lib/Support/APFloat.cpp#L3502-L3504

For example, notice how `semFloat8E5M2` vs `semFloat8E5M2FNUZ` differ in their minExponent values, respectively -14 vs -15:
https://github.com/llvm/llvm-project/blob/fe754dff6d7ed3f7d69e5a97846d9320cb407977/llvm/lib/Support/APFloat.cpp#L61-L63

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