[PATCH] D11393: [X86] Allow X86::COND_NE_OR_P and X86::COND_NP_OR_E to be reversed.

David Li via llvm-commits llvm-commits at lists.llvm.org
Thu Jan 21 14:44:05 PST 2016


davidxl added a comment.

Can we also add a test case that test this:

jcc1   BB1
jncc2 BB2

BB1:     // cold
...
BB2:
..

can be ordered 
correctly  into
jxxx ...
jxxx ...
BB2:
...
BB1:


================
Comment at: lib/Target/X86/X86InstrInfo.cpp:4212
@@ +4211,3 @@
+  case X86::COND_P_AND_NE:
+    // If FBB is null, it is implied to be the next block of MBB.
+    if (FBB == nullptr) {
----------------
Fix comment. It is not 'implied' -- this is guaranteed by AnalyzeBranch

================
Comment at: lib/Target/X86/X86InstrInfo.cpp:4214
@@ +4213,3 @@
+    if (FBB == nullptr) {
+      MachineFunction::iterator I = std::next(MBB.getIterator());
+      FBB = &*I;
----------------
Have a little wrapper 'getFallthroughBlock'

================
Comment at: test/CodeGen/X86/block-placement.ll:472
@@ -469,1 +471,3 @@
 ; CHECK: %entry
+; CHECK: %if.then
+; CHECK: %if.end
----------------
Can you make the ordering check more strict here?

================
Comment at: test/CodeGen/X86/block-placement.ll:493
@@ -496,3 +492,3 @@
   %cmp.i = fcmp une double 0.000000e+00, undef
   br i1 %cmp.i, label %if.then, label %if.end
 
----------------
to make the test more robust, perhaps annotate this branch with weights { 1, 1000} where from 'exit' block it is not likely to branch into if.then.

================
Comment at: test/CodeGen/X86/block-placement.ll:665
@@ +664,3 @@
+; This branch is now analyzable and hence the destination block becomes the
+; hotter one.
+;
----------------
comment that the right order is : entry -> bar -> exit -> foo

================
Comment at: test/CodeGen/X86/block-placement.ll:669
@@ -669,4 +668,3 @@
 ; CHECK: %entry
-; CHECK: %foo
 ; CHECK: %bar
 ; CHECK: %exit
----------------
use check-next for more strict checking.


http://reviews.llvm.org/D11393





More information about the llvm-commits mailing list