[flang-commits] [flang] [mlir] [RFC][mlir] ViewLikeOpInterface method for detecting partial views. (PR #164020)

[Slava Zakharin via flang-commits]

================
@@ -23,21 +23,53 @@ def ViewLikeOpInterface : OpInterface<"ViewLikeOpInterface"> {
   }];
   let cppNamespace = "::mlir";
 
-  let methods = [
-    InterfaceMethod<
-      "Returns the source buffer from which the view is created.",
-      "::mlir::Value", "getViewSource">,
-    InterfaceMethod<
-      /*desc=*/[{ Returns the buffer which the view created. }],
-      /*retTy=*/"::mlir::Value",
-      /*methodName=*/"getViewDest",
-      /*args=*/(ins),
-      /*methodBody=*/"",
-      /*defaultImplementation=*/[{
+  let methods =
+      [InterfaceMethod<
+           "Returns the source buffer from which the view is created.",
+           "::mlir::Value", "getViewSource">,
+       InterfaceMethod<
+           /*desc=*/[{ Returns the buffer which the view created. }],
+           /*retTy=*/"::mlir::Value",
+           /*methodName=*/"getViewDest",
+           /*args=*/(ins),
+           /*methodBody=*/"",
+           /*defaultImplementation=*/[{
         return $_op->getResult(0);
-      }]
-    >
-  ];
+      }]>,
+       InterfaceMethod<
+           /*desc=*/
+           [{
+             Returns true iff the source buffer and the resulting view
+             are known to start at the same "address".
+           }],
+           /*retTy=*/"bool",
+           /*methodName=*/"isKnownToHaveSameStart",
----------------
vzakhari wrote:

Yes, I think adding a method like `alias` will allow me to make the same changes in the alias analyses.

At the same time, I think the new `alias` method may become redundant if we decide to add the two more "basic" methods like `isKnownToHaveSameStart`/`isKnownToBeCompleteView` in future.

I think the following pieces of "basic" information provide everything we need to make a decision about the aliasing of the input and resulting views:
* Can we prove that the resulting view is a complete view of the input view? This method may return `true` even in cases when the views have dynamic sizes, e.g. based on the semantics of the concrete operation.
* Constant size of the input and the resulting views (or nullopt).
* Constant offset applied to the resulting input view to produce the resulting view (or nullopt).  `isKnownToHaveSameStart` is a simplified version of this query, i.e. it only says if the offset is zero and does not care to compute the actual non-zero constant offset, if it is possible.

I believe having these "basic" methods available, we can implement `alias` for all operations with `ViewLikeOpInterface`, and the concrete operations won't have any extra knowledge that will make sense overriding the `alias` method. That is why I decided to go with more "basic" methods (that may also be useful outside of the alias analysis, probably).

With that said, I agree replacing the two methods with an `alias` method. We can always adjust it in future if we end up adding all the method providing the "basic" information.

I can think of the following specification for the new `alias` method:
* This method returns AliasResult::Kind representing the aliasing between the input and the resulting views of a `ViewLikeOpInterface` operation.
* It returns `NoAlias` only when the resulting view is known to have zero size.  Note that when the input view has zero size the resulting view must have zero size as well. Otherwise,
* it returns `MustAlias` when the resulting view is known to start at the same address as the input view. Otherwise,
* it returns `PartialView` when the resulting view is known to start at a non-zero offset of the input view. Otherwise,
* it returns `MayAlias`.

Does this definition make sense to you?

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