[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