[all-commits] [llvm/llvm-project] e652c0: [X86] Teach lowerShuffleAsBlend to use bit blend f...

[topperc via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: e652c0f8f3e7c7a1b42edf22cfc5bbfd597fd164
      https://github.com/llvm/llvm-project/commit/e652c0f8f3e7c7a1b42edf22cfc5bbfd597fd164
  Author: Craig Topper <craig.topper at intel.com>
  Date:   2020-07-04 (Sat, 04 Jul 2020)

  Changed paths:
    M llvm/lib/Target/X86/X86ISelLowering.cpp
    M llvm/test/CodeGen/X86/prefer-avx256-mask-shuffle.ll
    M llvm/test/CodeGen/X86/shuffle-vs-trunc-256.ll
    M llvm/test/CodeGen/X86/vector-fshl-128.ll
    M llvm/test/CodeGen/X86/vector-fshl-256.ll
    M llvm/test/CodeGen/X86/vector-fshr-128.ll
    M llvm/test/CodeGen/X86/vector-fshr-256.ll
    M llvm/test/CodeGen/X86/vector-shuffle-v48.ll

  Log Message:
  -----------
  [X86] Teach lowerShuffleAsBlend to use bit blend for v16i8/v32i8/v16i16 when avx512vl is enabled but not avx512bw.

Probably not super important since there are no real CPUs with
avx512vl and not avx512bw. But vpternlog should be better than
vblendvb.

I do wonder if we should use vpternlog even with BWI. We
currently use vblendmb or vpblendmw by putting the mask into a GPR
and moving it to a k-register. But I don't think we hoist the
GPR to k-register copy in machine LICM. Using VPTERNLOG would use
a constant pool load, but has the advantage that we're pretty good
at hoisting and rematerializing those.

Reviewed By: RKSimon

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