[flang-commits] [flang] [mlir] [mlir][CSE] Introduce hoist-pure-ops logic to CSE pass (PR #180556)

[Mehdi Amini via flang-commits]

================
@@ -0,0 +1,41 @@
+//===- HoistingContainerOpInterface.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 HoistingContainerOpInterface. 
+//
+//===----------------------------------------------------------------------===//
+
+#ifndef MLIR_INTERFACES_HOISTING_CONTAINER_OP_INTERFACE
+#define MLIR_INTERFACES_HOISTING_CONTAINER_OP_INTERFACE
+
+include "mlir/IR/OpBase.td"
+
+def HoistingContainerOpInterface : OpInterface<"HoistingContainerOpInterface"> {
+  let description = [{
+    This interface models whether an operation's regions are capable of 
+    acting as a container for operations hoisted from nested regions.
----------------
joker-eph wrote:

>  is the decision definitely that restrictions in operations preventing this sort of hoisting (e.g. loop wrappers in the OpenMP dialect) are incorrect and should be fixed in the long term?

This is just my opinion, we haven't written it down anywhere, but to me the op should be "isolated from above" or not have restriction on SSA value coming from above.
Composition of transformations makes it hard to play with operations wrappers that restrict the transformations in their immediate body. If you think about it that looks like we could intrerpose a [scf.execute_region](https://mlir.llvm.org/docs/Dialects/SCFDialect/#scfexecute_region-scfexecuteregionop) everywhere to work around this restriction, but I'd wonder why is this restriction there in the first place?

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