Notes on how to kill the eeevil brtwoway, and make ppc branch selector

more target independant, generate better code, and be less conservative.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@26809 91177308-0d34-0410-b5e6-96231b3b80d8

diff --git a/lib/Target/PowerPC/README.txt b/lib/Target/PowerPC/README.txt
index 28e6d3ded01edcd8657e2d0774bdd9e344038ae4..0024fabf86ac7868f66428eb85b1e7d9d76ef401 100644 (file)
--- a/lib/Target/PowerPC/README.txt
+++ b/lib/Target/PowerPC/README.txt
@@ -18,6 +18,34 @@ unconditional branch, so we don't end up with things like:
 
 This occurs in SPASS.
 
+The power of diet coke came up with a solution to this today:
+
+We know the only two cases that can happen here are either:
+a) we have a conditional branch followed by a fallthrough to the next BB
+b) we have a conditional branch followed by an unconditional branch
+
+We also invented the BRTWOWAY node to model (b).
+
+Currently, these are modeled by the PPC_BRCOND node which is a 12-byte pseudo
+that codegens to 
+  bccinv false
+true:
+  b truebb
+false:
+  b falsebb 
+
+However, realizing that for (a), we can bccinv directly to the fallthrough 
+block, and for (b) we will already have another unconditional branch after
+the conditional branch (see SPASS case above), then we know that we don't need
+BRTWOWAY at all, and can just codegen PPC_BRCOND as 
+
+bccinv +8
+b truebb
+
+This will also allow us to selectively not run the ppc branch selector, by just
+selecting PPC_BRCOND pseudo directly to the correct conditional branch
+instruction for small functions.
+
 ===-------------------------------------------------------------------------===
 
 * Codegen this: