[PATCH] D82049: Fix crash in VectorCombine when attempting to peephole ConstantVector sequences

[Sanjay Patel via Phabricator via llvm-commits]

spatel added a comment.

Was this found by a fuzzer, or is this part of a real compilation?
Either way, I'm worried that we may find more cases like this because we've generally assumed that code is coming into -vector-combine in mostly optimized form.

Maybe it's better to cheaply pre-process a block before trying anything in this pass? That way, we won't get sidetracked even if something like SLP has left stray code in the function.

  diff --git a/llvm/lib/Transforms/Vectorize/VectorCombine.cpp b/llvm/lib/Transforms/Vectorize/VectorCombine.cpp
  index 05f9c6f7daf..7c4c61f8bb6 100644
  --- a/llvm/lib/Transforms/Vectorize/VectorCombine.cpp
  +++ b/llvm/lib/Transforms/Vectorize/VectorCombine.cpp
  @@ -445,6 +445,9 @@ static bool runImpl(Function &F, const TargetTransformInfo &TTI,
       // Ignore unreachable basic blocks.
       if (!DT.isReachableFromEntry(&BB))
         continue;
  +
  +    MadeChange |= SimplifyInstructionsInBlock(&BB);
  +
       // Do not delete instructions under here and invalidate the iterator.
       // Walk the block forwards to enable simple iterative chains of transforms.
       // TODO: It could be more efficient to remove dead instructions



================
Comment at: llvm/test/Transforms/VectorCombine/X86/ignore-const.ll:12
+; Function Attrs: norecurse nounwind uwtable
+define dso_local i32 @main() local_unnamed_addr #0 {
+; CHECK-LABEL: @main(
----------------
We can reduce the test to something like this:


```
define i32 @constant_fold_crash(<4 x i32> %x) {
  %c = extractelement <4 x i32> <i32 16, i32 17, i32 18, i32 19>, i32 1
  %d = extractelement <4 x i32> %x, i64 0
  %e = add i32 %c, %d
  ret i32 %e
}

```


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D82049/new/

https://reviews.llvm.org/D82049