diff options
author | Richard Sandiford <rsandifo@linux.vnet.ibm.com> | 2013-08-05 11:23:46 +0000 |
---|---|---|
committer | Richard Sandiford <rsandifo@linux.vnet.ibm.com> | 2013-08-05 11:23:46 +0000 |
commit | 93795574785de252703591e7fcc8f052c762f25e (patch) | |
tree | de693d743c5334444b688797de354cdc279bbdbe /lib/Target/SystemZ/SystemZTargetMachine.cpp | |
parent | f8e16c6f5a3a0d2cc6f7ae6dae0a8f55a89cfb2f (diff) | |
download | llvm-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.cpp | 3 |
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. |