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

[Markus Böck]

================
@@ -0,0 +1,48 @@
+//===- ExecutionProgressOpInterface.td - Interface Decl. -*- tablegen -*---===//
+//
+// 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
+//
+//===----------------------------------------------------------------------===//
+//
+// This is the definition file for the ExecutionProgressOpInterface.
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef MLIR_INTERFACES_EXECUTION_PROGRESS_OP_INTERFACE
+#define MLIR_INTERFACES_EXECUTION_PROGRESS_OP_INTERFACE
+
+include "mlir/IR/OpBase.td"
+
+def ExecutionProgressOpInterface : OpInterface<"ExecutionProgressOpInterface"> {
+  let description = [{
+    This interface models execution progress properties of operations.
+  }];
+  let cppNamespace = "::mlir";
+  let methods = [
+    InterfaceMethod<
+      /*desc=*/[{
+        Operations that "must progress" are required to return normally (control
+        flow reaches the next operation) or interact with the environment in an
+        observable way (e.g., volatile memory access, I/O, synchronization or
+        program termination). If a "must progress" op executes indefinitely
+        without any observable interaction, it may be erased.
----------------
zero9178 wrote:

I think it being UB is the most accurate yeah. 
One could also phrase the above in terms of MLIR lingo in that if the operation has no side-effects and mustProgress is true, then it is undefined behaviour for the operation after not to be reached.

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