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

[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?
----------------
jeanPerier wrote:

Are you talking about the result of a same operation with multiple results, or the result of different operation.

If this is about the former, it seems to ne the caching would be overkill given the average number or results in operation. If this is about the later, it seems to me that maintaining some shared cache somewhere would not be cheap, is the call to `isCompatibleType` that expensive?

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