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

[Tom Eccles 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.
----------------
tblah wrote:

> I'd wonder why is this restriction there in the first place?

Thanks for explaining. For the case of the OpenMP loop wrappers there are a series of operations wrapping around a loop. This is created by a series of nested operations so that different operations can be composed together to create different composite loop constructs. It doesn't make very good semantic sense for any operation to be inserted in the middle (although one could just insert them immediately before the nested loop). In the end, that is an additional implementation complexity which has so far been avoided by this restriction. The loop wrappers are not isolated from above because (most of them) don't behave like that, plus it would be inconvenient to implement because every value referred to inside the loop body would have to be passed through every single isolated from above wrapper.

There was more discussion of the reasoning for the HLFIR opreration design in https://discourse.llvm.org/t/make-hlfir-forall-can-contain-pureop

None of these issues would be impossible to work around but I think it could be inconvenient.

See also Jean Perier's [comment](https://discourse.llvm.org/t/make-hlfir-forall-can-contain-pureop/89805/4?u=tblah) about unconditionally moving pure operations which are computationally expensive.

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