[llvm] [LAA] Consider unknown SCEVs defined in the loop as IndirectUnsafe. (PR #99239)

[Florian Hahn via llvm-commits]

fhahn wrote:

> I'm missing something here. Why should the index being loop variant prevent us from grouping accesses by underlying objects and proving no-overlap for accesses whose entire access range can't overlap? Given one access to object A (with a runtime offset), and an object B (which we load that offset from), if A and B can't overlap, why do we need to prevent that vectorization?
> 
> Are we maybe failing to perform accurate checking _within_ a single object?

Yes, the issue in the `@B_indices_loaded_in_loop_A_stored` is limited to the accesses to object `%B` which is indexed by a value loaded on each iteration. Because the both load and store use the same address, the distance between them is 0 and at the moment we determine there's no dependence between them. There can be however, e.g. if the loaded index for 2 consecutive iterations is the same, the later iteration depends on the earlier one.

The mention of runtime checks in the commit message may have been a bit confusing, the part they play is that in some cases we re-try generating runtime checks if there are certain kinds of unknown dependences, which is where the load and store of to object `%A` come in; without them, the function is not considered safe for vectorization already. 

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