[llvm] [SimplifyCFG] Avoid sinking loads/stores that impact vectorization (PR #222587)

[Ashutosh Nema via llvm-commits]

nema-ashutosh wrote:

> Is the transform profitable even if we do not vectorize? Can you add a test where we perform the transform but still cannot vectorized (e.g. due to dependency, unvectorizable call etc)

Thanks for the suggestion.

Sinking is still the default. We only skip it when the access is unit stride and a masked load/store is legal for the target, as a cheap stand-in for what the vectorizer would likely do. We don’t try to decide whether the loop as a whole is vectorizable (calls, dependences, costs, etc.).

The cases where we still sink are @non_loop_*, @strided_*, and @*_unsupported_type in sink-common-{load,store}-different-pointers.ll, plus the SCALAR (+sse2) runs.

This also means we may skip sinking in a consecutive loop even when it later cannot vectorize. We treat that as a limit of the approximation rather than something SimplifyCFG should diagnose.

I can add a test that shows that case if it would help.

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