[flang-commits] [flang] [flang] Disambiguate derived component accesses in AliasAnalysis. (PR #189516)

[via flang-commits]

jeanPerier wrote:

I think Tom example is failing with your patch because the alias() code [here](https://github.com/llvm/llvm-project/blob/efbd59631091fdf4ed3c0f33343ccd63dd896e00/flang/lib/Optimizer/Analysis/AliasAnalysis.cpp#L390-L393) is claiming that "Handling of non-data is included below." while it is not really covered below and just falling back to NoAlias.

I have trouble wrapping my head around the "following data" concept every time I read that code again in a review. I wonder if we would not be better without it (or at least reverse it to a "descriptor address" concept, or find another way to reason about things.
For instance, instead of walking back indirect loads and mix attributes, we could try to add a field in the Source to store POINTER/ALLOCATABLE sources for indirect loads and then try to analyze whether these POINTERS/ALLOCTABLEs can be associated with the source for the other memory slot being analyzed.

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