[flang-commits] [flang] [mlir] [RFC][mlir] Conditional support for fast-math attributes. (PR #125620)

[Slava Zakharin via flang-commits]

================
@@ -66,3 +67,49 @@ Operation *arith::ArithDialect::materializeConstant(OpBuilder &builder,
 
   return ConstantOp::materialize(builder, value, type, loc);
 }
+
+/// Return true if the type is compatible with fast math, i.e.
+/// it is a float type or contains a float type.
+bool arith::ArithFastMathInterface::isCompatibleType(Type type) {
+  if (isa<FloatType>(type))
+    return true;
+
+  // ShapeType's with ValueSemantics represent containers
+  // passed around as values (not references), so look inside
+  // them to see if the element type is compatible with FastMath.
+  if (type.hasTrait<ValueSemantics>())
+    if (auto shapedType = dyn_cast<ShapedType>(type))
+      return isCompatibleType(shapedType.getElementType());
+
+  // ComplexType's element type is always a FloatType.
+  if (auto complexType = dyn_cast<ComplexType>(type))
+    return true;
+
+  // TODO: what about TupleType and custom dialect struct-like types?
+  // It seems that they worth an interface to get to the list of element types.
+  //
+  // NOTE: LLVM only allows fast-math flags for instructions producing
+  // structures with homogeneous floating point members. I think
+  // this restriction must not be asserted here, because custom
+  // MLIR operations may be converted such that the original operation's
+  // FastMathFlags still need to be propagated to the target
+  // operations.
+
+  return false;
+}
+
+/// Return true if any of the results of the operation
+/// has a type compatible with fast math, i.e. it is a float type
+/// or contains a float type.
+///
+/// TODO: the results often have the same type, and traversing
+/// the same type again and again is not very efficient.
+/// We can cache it here for the duration of the processing.
+/// Other ideas?
----------------
vzakhari wrote:

Any suggestions about this?

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