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

[Slava Zakharin via flang-commits]

================
@@ -40,17 +40,19 @@ using namespace mlir;
 static constexpr unsigned maxUnderlyingValueSearchDepth = 10;
 
 /// Given a value, collect all of the underlying values being addressed.
-static void collectUnderlyingAddressValues(Value value, unsigned maxDepth,
-                                           DenseSet<Value> &visited,
-                                           SmallVectorImpl<Value> &output);
+static void
+collectUnderlyingAddressValues(Value value, unsigned maxDepth,
+                               DenseMap<Value, bool> &visited, bool maybeOffset,
+                               SmallVectorImpl<std::pair<Value, bool>> &output);
----------------
vzakhari wrote:

I will desribe it in the comments, but here is a short summary.

The alias analysis starts at two pointers and walks back the def-use chains. If there is a view-like operation, the walk is continued for the view-source. Eventually, the alias analysis reaches a set of object definitions (e.g. values for which the further walk is not possible), and then uses these object definitions to match them agains each other. For example, if for the two pointers we collected exactly two object definitions (one for each pointer), and they are the same Values, the alias analysis may think that this is a `MustAlias` case. This might be not correct, if during the walk we met two different view-like operations and they applied some non-equal offsets to the same object definition, e.g.:
```
  %obj = ...
  %view1 = view of %obj with offset 0
  %view2 = view of %obj with offset %off
  access %view1
  access %view2
```

Consider the following cases for the value of `%off`:
* If it is statically known to be 0, then we should report `MustAlias`.
* If it is statically known to be not 0, then we should report `PartialAlias`.
* If its value is unknown, then we should probably report `MayAlias` (meaning that it might be either `PartialAlias` or `MustAlias`).

My change is not trying to reason about the offset value, and uses the `maybeOffset` attribute to propagate the information that some offset may be applied to the object definition to produce the value of the pointer for which the alias analysis is being queried.

Ideally, the alias analysis should also take into account the size of the accesses through the two pointers, so that it can reason about aliasing within the same object given the sizes and the accumulated offsets.

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