summaryrefslogtreecommitdiffstats
path: root/llvm/lib/CodeGen/PeepholeOptimizer.cpp
diff options
context:
space:
mode:
authorChandler Carruth <chandlerc@gmail.com>2018-07-24 00:21:59 +0000
committerChandler Carruth <chandlerc@gmail.com>2018-07-24 00:21:59 +0000
commitb46c22de006a2c48774c4d449b18fda2e07ad948 (patch)
tree4beb51222bda2130bfa70e995232ce3bb42d2192 /llvm/lib/CodeGen/PeepholeOptimizer.cpp
parent7adcf292a1b151d25accced68d3a12b8e2e0c68c (diff)
downloadbcm5719-llvm-b46c22de006a2c48774c4d449b18fda2e07ad948.tar.gz
bcm5719-llvm-b46c22de006a2c48774c4d449b18fda2e07ad948.zip
[x86/SLH] Remove complex SHRX-based post-load hardening.
This code was really nasty, had several bugs in it originally, and wasn't carrying its weight. While on Zen we have all 4 ports available for SHRX, on all of the Intel parts with Agner's tables, SHRX can only execute on 2 ports, giving it 1/2 the throughput of OR. Worse, all too often this pattern required two SHRX instructions in a chain, hurting the critical path by a lot. Even if we end up needing to safe/restore EFLAGS, that is no longer so bad. We pay for a uop to save the flag, but we very likely get fusion when it is used by forming a test/jCC pair or something similar. In practice, I don't expect the SHRX to be a significant savings here, so I'd like to avoid the complex code required. We can always resurrect this if/when someone has a specific performance issue addressed by it. llvm-svn: 337781
Diffstat (limited to 'llvm/lib/CodeGen/PeepholeOptimizer.cpp')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud