[Mlir-commits] [mlir] [mlir][Interfaces] Add `ExecutionProgressOpInterface` + folding pattern (PR #179039)

[Matthias Springer]

================
@@ -0,0 +1,23 @@
+//===- ExecutionProgressOpInterface.cpp -- Execution Progress Interface ---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#include "mlir/Interfaces/ExecutionProgressOpInterface.h"
+
+using namespace mlir;
+
+namespace mlir {
+#include "mlir/Interfaces/ExecutionProgressOpInterface.cpp.inc"
+} // namespace mlir
+
+bool mlir::mustProgress(Operation *op) {
+  auto executionProgressOpInterface =
+      dyn_cast<ExecutionProgressOpInterface>(op);
+  if (!executionProgressOpInterface)
+    return false;
----------------
matthias-springer wrote:

I changed this based on @zero9178's comment above: If we don't know whether an op must progress or not, it's better to give a conservative answer. A return value of "false" doesn't give us any information: the op may progress or it may not.

Returning "true" may enable additional transformations, which could be incorrect. (E.g., unregistered ops may implement the `ExecutionProgressOpInterface`, but we do not know that.)

So far, we have treated the implementation of op interfaces as optional throughout the code base. E.g., that's the design that we use for the `MemoryEffectOpInterface`.

* Op does implement the `MemoryEffectOpInterface` => side effects are modeled.
* Op does not implement the `MemoryEffectOpInterface` => we revert to the conservative case: assuming that the op may have side effects.





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