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

[Razvan Lupusoru]

razvanlupusoru wrote:

Hi Slava! Thank you for your proposal! I agree with your points:
- Partial overlaps should not report `MustAlias`. However, I can see that if an implementation tries to find the "parent" and then compares just the parent, then this is the expected result but not the correct one.
- I agree that `isSameStart` is likely not adequate (eg trying to determine aliasing between a base object and the field at offset 0).

**Core issue: ViewLikeOpInterface is overloaded**

Looking at the MemRef dialect, `ViewLikeOpInterface` is currently used for two fundamentally different categories of operations:

Category 1: Complete alias (same entity, different type):
- `memref.cast` - "converts a memref from one type to an equivalent type" - the entire source aliases with the entire result
- `memref.assume_alignment` - adds alignment information, complete alias
- `memref.memory_space_cast` - changes memory space, complete alias
- `memref.reshape` / `expand_shape` / `collapse_shape` - changes shape layout, complete alias

Category 2: Partial overlap (subset of entity):
- `memref.subview` - "represents a **reduced-size view** of the original memref" - only a subset of the source aliases with the result

Thus, when `LocalAliasAnalysis::collectUnderlyingAddressValues` unwraps ViewLikeOpInterface, it treats `memref.subview` (partial) the same as `memref.cast` (complete), causing the MustAlias issue you observed.

**Proposed solution:**

I suggest introducing a `SubviewLikeOpInterface` (or `PartialViewOpInterface`) to distinguish operations that create partial views from those that merely change types. This would allow:
1. LocalAliasAnalysis and FIR AliasAnalysis to correctly handle partial overlaps (PartialAlias)
2. Complete view operations to continue being optimized as full aliases (MustAlias)

This would make `ViewLikeOpInterface` match my own intuition that it represents the same original entity. `memref.subview` and similar operations would implement the new interface, while `memref.cast` etc. would remain with ViewLikeOpInterface.

Operations like `fir.coordinate_of`, `fir.array_coor`, and `hlfir.designate` could then implement `SubviewLikeOpInterface`, enabling correct alias analysis for Fortran derived types and arrays.

What do you think?

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