[llvm] [LoadStoreVectorizer] Allow vectorization of partially overlapped vector-stores (PR #169946)

[Drew Kersnar via llvm-commits]

dakersnar wrote:

Unfortunately, I found a case where this miscompiles. The problem is that the "ok" on aliasing within chain is only valid if the aliasing elements remain in a chain together. If they pass the alias check but then later the chain gets split up, the move is no longer valid.

```
; NOTE: Assertions have been autogenerated by utils/update_test_checks.py UTC_ARGS: --version 5
; RUN: opt -mtriple=x86_64-unknown-linux-gnu -passes=load-store-vectorizer -S < %s | FileCheck %s

; Note: For this target, unalgined 4x32s are blocked, 3x32s are allowed.
; This results in Store4 extending too far to be vectorized, but it aliases with store3, and this change
; prevents that alias from blocking the incorrect vectorization,
; since store4 starts out in the chain, despite being dropped from the chain later.


; BEFORE VECTORIZATION stored values: 5 2 4 4
; ______ ______ ______ ______
; store1 ------ ------ ------
; ------ store2 ------ ------
; ------ ------ store3 ------
; ------ ------ store4 store4
; store5 ------ ------ ------

; AFTER VECTORIZATION stored values: 5 2 *3* 4
; ______ ______ ______ ______
; ------ ------ store4 store4
; store5 store2 store3 ------

define void @test_redundant(ptr %ptr) {
; CHECK-LABEL: define void @test_redundant(
; CHECK-SAME: ptr [[PTR:%.*]]) {
; CHECK-NEXT:    [[GEP1:%.*]] = getelementptr inbounds i8, ptr [[PTR]], i32 8
; CHECK-NEXT:    store <2 x i32> splat (i32 4), ptr [[GEP1]], align 4
; CHECK-NEXT:    store <3 x i32> <i32 5, i32 2, i32 3>, ptr [[PTR]], align 4
; CHECK-NEXT:    ret void
;
  %gep4 = getelementptr inbounds i8, ptr %ptr, i32 4
  %gep8 = getelementptr inbounds i8, ptr %ptr, i32 8
  store i32 1, ptr %ptr, align 4
  store i32 2, ptr %gep4, align 4
  store i32 3, ptr %gep8, align 4
  store <2 x i32> <i32 4, i32 4>, ptr %gep8, align 4
  store i32 5, ptr %ptr, align 4
  ret void
}
```

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