aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/CodeGen/CodeGenFunction.cpp
diff options
context:
space:
mode:
authorSanjay Patel <spatel@rotateright.com>2020-02-16 10:32:56 -0500
committerSanjay Patel <spatel@rotateright.com>2020-02-16 10:32:56 -0500
commite48b536be66b60b05fa77b85258e6cf2ec417220 (patch)
tree070c6de1bb6998f795709bd127f5caff820eeb0d /clang/lib/CodeGen/CodeGenFunction.cpp
parent893c630fbe393916d9b7e07a5ac58046ea5db30e (diff)
downloadllvm-e48b536be66b60b05fa77b85258e6cf2ec417220.zip
llvm-e48b536be66b60b05fa77b85258e6cf2ec417220.tar.gz
llvm-e48b536be66b60b05fa77b85258e6cf2ec417220.tar.bz2
[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
Diffstat (limited to 'clang/lib/CodeGen/CodeGenFunction.cpp')
0 files changed, 0 insertions, 0 deletions