[all-commits] [llvm/llvm-project] e48b53: [x86] form broadcast of scalar memop even with >1 use

[RotateRight via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: e48b536be66b60b05fa77b85258e6cf2ec417220
      https://github.com/llvm/llvm-project/commit/e48b536be66b60b05fa77b85258e6cf2ec417220
  Author: Sanjay Patel <spatel at rotateright.com>
  Date:   2020-02-16 (Sun, 16 Feb 2020)

  Changed paths:
    M llvm/lib/Target/X86/X86ISelLowering.cpp
    M llvm/test/CodeGen/X86/avg.ll
    M llvm/test/CodeGen/X86/avx512-shuffles/partial_permute.ll
    M llvm/test/CodeGen/X86/extract-concat.ll
    M llvm/test/CodeGen/X86/merge-consecutive-stores-nt.ll
    M llvm/test/CodeGen/X86/oddshuffles.ll
    M llvm/test/CodeGen/X86/pr34653.ll
    M llvm/test/CodeGen/X86/vec-strict-cmp-sub128.ll
    M llvm/test/CodeGen/X86/vector-reduce-fadd.ll
    M llvm/test/CodeGen/X86/vector-reduce-fmul.ll
    M llvm/test/CodeGen/X86/vector-shuffle-combining.ll

  Log Message:
  -----------
  [x86] form broadcast of scalar memop even with >1 use

The unseen logic diff occurs because MayFoldLoad() is defined like this:

static bool MayFoldLoad(SDValue Op) {
  return Op.hasOneUse() && ISD::isNormalLoad(Op.getNode());
}

The test diffs here all seem ok to me on screen/paper, but it's hard to know
if that will lead to universally better perf for all targets. For example,
if a target implements broadcast from mem as multiple uops, we would have to
weigh the potential reduction of instructions and register pressure vs.
possible increase in number of uops. I don't know if we can make a truly
informed decision on this at compile-time.

The motivating case that I'm looking at in PR42024:
https://bugs.llvm.org/show_bug.cgi?id=42024
...resembles the diff in extract-concat.ll, but we're not going to change the
larger example there without at least 1 other fix.

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