summaryrefslogtreecommitdiff
path: root/lib/Target/SystemZ/SystemZTargetMachine.cpp
diff options
context:
space:
mode:
authorRichard Sandiford <rsandifo@linux.vnet.ibm.com>2013-08-05 11:23:46 +0000
committerRichard Sandiford <rsandifo@linux.vnet.ibm.com>2013-08-05 11:23:46 +0000
commit93795574785de252703591e7fcc8f052c762f25e (patch)
treede693d743c5334444b688797de354cdc279bbdbe /lib/Target/SystemZ/SystemZTargetMachine.cpp
parentf8e16c6f5a3a0d2cc6f7ae6dae0a8f55a89cfb2f (diff)
downloadllvm-93795574785de252703591e7fcc8f052c762f25e.tar.gz
llvm-93795574785de252703591e7fcc8f052c762f25e.tar.bz2
llvm-93795574785de252703591e7fcc8f052c762f25e.tar.xz
[SystemZ] Use BRCT and BRCTG to eliminate add-&-compare sequences
This patch just uses a peephole test for "add; compare; branch" sequences within a single block. The IR optimizers already convert loops to decrement-and-branch-on-nonzero form in some cases, so even this simplistic test triggers many times during a clang bootstrap and projects/test-suite run. It looks like there are still cases where we need to more strongly prefer branches on nonzero though. E.g. I saw a case where a loop that started out with a check for 0 ended up with a check for -1. I'll try to look at that sometime. I ended up adding the Reference class because MachineInstr::readsRegister() doesn't check for subregisters (by design, as far as I could tell). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187723 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'lib/Target/SystemZ/SystemZTargetMachine.cpp')
-rw-r--r--lib/Target/SystemZ/SystemZTargetMachine.cpp3
1 files changed, 3 insertions, 0 deletions
diff --git a/lib/Target/SystemZ/SystemZTargetMachine.cpp b/lib/Target/SystemZ/SystemZTargetMachine.cpp
index 2bacc2bc24..856183c6f4 100644
--- a/lib/Target/SystemZ/SystemZTargetMachine.cpp
+++ b/lib/Target/SystemZ/SystemZTargetMachine.cpp
@@ -82,6 +82,9 @@ bool SystemZPassConfig::addPreEmitPass() {
// CC values (while still being worthwhile) and others that happen to make
// the CC result more useful than it was originally.
//
+ // Another reason is that we only want to use BRANCH ON COUNT in cases
+ // where we know that the count register is not going to be spilled.
+ //
// Doing it so late makes it more likely that a register will be reused
// between the comparison and the branch, but it isn't clear whether
// preventing that would be a win or not.