[flang-commits] [flang] [flang] Support fir.pack_array in FIR alias analysis. (PR #131946)

[Slava Zakharin via flang-commits]

vzakhari wrote:

> @vzakhari, I think the `approximateSource` field should be set to avoid `MustAlias` to be returned when comparing the output and input and weird things happening from the fact that they may not be the same thing (I cannot think of anything, but a crazy optimization could maybe assume it does not have address offsets if the base is an exact alias of some already computed offset, like doing CSE of hlfir.designate using aliasing).

I think it should be okay to return `MustAlias` for two memory references even if one of the points to the original array and the other points to the temporary array.  By lowering, such memory references must be located on the opposite sides of either `fir.pack_array` or `fir.unpack_array`, and they cannot be moved around by any pass due to the memory effects of these operations.  Next, even if we report `MustAlias`, what kind of optimization can be done on the corresponding memory accesses?  I cannot think of anythign, because, again, there will be `fir.pack_array` or `fir.unpack_array` in the middle that will disallow any assumptions about the values read/written to/from the two locations in memory.  The `approximateSource` will be set, if there is address offsets (designator/array_coor/etc.) applied to the two memory references, so I do not think we need to set it just due to the fact that we reached a `fir.pack_array`.

Moreover, I think it will be counterproductive to set `approximateSource` upon reaching `fir.pack_array`.  For example, this will prevent any memory CSE for memory accesses addressing off the result of `fir.pack_array` when they are located inside the repacking scope.

Please let me know if there is a particular (even imaginary :) ) example that I am missing.  I will not merge this PR just yet.


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