[Mlir-commits] [mlir] [mlir][emitc] Support convert arith.extf and arith.truncf to emitc (PR #121184)

Marius Brehler llvmlistbot at llvm.org
Thu Jan 2 01:42:12 PST 2025


================
@@ -733,6 +733,43 @@ class ItoFCastOpConversion : public OpConversionPattern<CastOp> {
   }
 };
 
+// Floating-point to floating-point conversions.
+template <typename CastOp>
+class FpCastOpConversion : public OpConversionPattern<CastOp> {
+public:
+  FpCastOpConversion(const TypeConverter &typeConverter, MLIRContext *context)
+      : OpConversionPattern<CastOp>(typeConverter, context) {}
+
+  LogicalResult
+  matchAndRewrite(CastOp castOp, typename CastOp::Adaptor adaptor,
+                  ConversionPatternRewriter &rewriter) const override {
+    // Vectors in particular are not supported
+    Type operandType = adaptor.getIn().getType();
+    if (!emitc::isSupportedFloatType(operandType))
+      return rewriter.notifyMatchFailure(castOp,
+                                         "unsupported cast source type");
+    if (auto roundingModeOp =
+            dyn_cast<arith::ArithRoundingModeInterface>(*castOp)) {
+      // Only supporting default rounding mode as of now.
+      if (roundingModeOp.getRoundingModeAttr())
----------------
marbre wrote:

Without looking further into the underlying code, is a `RoundingModeAttr` also provided for the default rounding mode? I think a test as suggested by @TinaAMD would help.

Furthermore, do we know what the default rounding mode is that's assumed by Arith? And is this what we would expect with C or C++? For C, https://en.cppreference.com/w/c/language/conversion (*Real floating-point conversions*) says
><p>A value of any real floating type can be implicitly converted to any other real floating type.
></p>
><ul><li> If the value can be represented by the target type exactly, it is unchanged
></li><li> if the value can be represented, but cannot be represented 
>exactly, the result is the nearest higher or the nearest lower value (in
 >other words, rounding direction is implementation-defined), although if
 >IEEE arithmetic is supported, rounding is to nearest
></li><li> if the value cannot be represented, the behavior is undefined <br>
> | This section is incompleteReason: check IEEE if appropriately-signed infinity is required |


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


More information about the Mlir-commits mailing list