[all-commits] [llvm/llvm-project] f575f1: [InstCombine] remove identity shuffle simplificati...

[RotateRight via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: f575f12c646544a3200852cf72212045fdf2e0b4
      https://github.com/llvm/llvm-project/commit/f575f12c646544a3200852cf72212045fdf2e0b4
  Author: Sanjay Patel <spatel at rotateright.com>
  Date:   2019-11-24 (Sun, 24 Nov 2019)

  Changed paths:
    M llvm/lib/Transforms/InstCombine/InstCombineSimplifyDemanded.cpp
    M llvm/lib/Transforms/InstCombine/InstCombineVectorOps.cpp
    M llvm/test/Transforms/InstCombine/X86/x86-avx2.ll
    M llvm/test/Transforms/InstCombine/X86/x86-avx512.ll
    M llvm/test/Transforms/InstCombine/X86/x86-fma.ll
    M llvm/test/Transforms/InstCombine/X86/x86-pack.ll
    M llvm/test/Transforms/InstCombine/X86/x86-pshufb.ll
    M llvm/test/Transforms/InstCombine/X86/x86-sse4a.ll
    M llvm/test/Transforms/InstCombine/X86/x86-vpermil.ll
    M llvm/test/Transforms/InstCombine/shuffle_select.ll
    M llvm/test/Transforms/InstCombine/vec_demanded_elts.ll
    M llvm/test/Transforms/InstCombine/vec_shuffle.ll

  Log Message:
  -----------
  [InstCombine] remove identity shuffle simplification for mask with undefs

And simultaneously enhance SimplifyDemandedVectorElts() to rcognize that
pattern. That preserves some of the old optimizations in IR.

Given a shuffle that includes undef elements in an otherwise identity mask like:

define <4 x float> @shuffle(<4 x float> %arg) {
  %shuf = shufflevector <4 x float> %arg, <4 x float> undef, <4 x i32> <i32 undef, i32 1, i32 2, i32 3>
  ret <4 x float> %shuf
}

We were simplifying that to the input operand.

But as discussed in PR43958:
https://bugs.llvm.org/show_bug.cgi?id=43958
...that means that per-vector-element poison that would be stopped by the shuffle can now
leak to the result.

Also note that we still have (and there are tests for) the same transform with no undef
elements in the mask (a fully-defined identity mask). I don't think there's any
controversy about that case - it's a valid transform under any interpretation of
shufflevector/undef/poison.

Looking at a few of the diffs into codegen, I don't see any difference in final asm. So
depending on your perspective, that's good (no real loss of optimization power) or bad
(poison exists in the DAG, so we only partially fixed the bug).

Differential Revision: https://reviews.llvm.org/D70246