[llvm] r318657 - [mips] Reorder target specific passes

Simon Dardis via llvm-commits llvm-commits at lists.llvm.org
Mon Nov 20 07:59:18 PST 2017


Author: sdardis
Date: Mon Nov 20 07:59:18 2017
New Revision: 318657

URL: http://llvm.org/viewvc/llvm-project?rev=318657&view=rev
Log:
[mips] Reorder target specific passes

Move the hazard scheduling pass to after the long branch pass, as the
long branch pass can create forbiddden slot hazards. Rather than complicating
the implementation of the long branch pass to handle forbidden slot hazards,
just reorder the passes.

Added:
    llvm/trunk/test/CodeGen/Mips/longbranch/
    llvm/trunk/test/CodeGen/Mips/longbranch/compact-branches-long-branch.ll
Modified:
    llvm/trunk/lib/Target/Mips/MipsTargetMachine.cpp

Modified: llvm/trunk/lib/Target/Mips/MipsTargetMachine.cpp
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/Mips/MipsTargetMachine.cpp?rev=318657&r1=318656&r2=318657&view=diff
==============================================================================
--- llvm/trunk/lib/Target/Mips/MipsTargetMachine.cpp (original)
+++ llvm/trunk/lib/Target/Mips/MipsTargetMachine.cpp Mon Nov 20 07:59:18 2017
@@ -278,12 +278,11 @@ TargetIRAnalysis MipsTargetMachine::getT
 void MipsPassConfig::addPreEmitPass() {
   addPass(createMicroMipsSizeReductionPass());
 
-  // The delay slot filler pass can potientially create forbidden slot (FS)
-  // hazards for MIPSR6 which the hazard schedule pass (HSP) will fix. Any
-  // (new) pass that creates compact branches after the HSP must handle FS
-  // hazards itself or be pipelined before the HSP.
+  // The delay slot filler and the long branch passes can potientially create
+  // forbidden slot/ hazards for MIPSR6 which the hazard schedule pass will
+  // fix. Any new pass must come before the hazard schedule pass.
   addPass(createMipsDelaySlotFillerPass());
-  addPass(createMipsHazardSchedule());
   addPass(createMipsLongBranchPass());
+  addPass(createMipsHazardSchedule());
   addPass(createMipsConstantIslandPass());
 }

Added: llvm/trunk/test/CodeGen/Mips/longbranch/compact-branches-long-branch.ll
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/test/CodeGen/Mips/longbranch/compact-branches-long-branch.ll?rev=318657&view=auto
==============================================================================
--- llvm/trunk/test/CodeGen/Mips/longbranch/compact-branches-long-branch.ll (added)
+++ llvm/trunk/test/CodeGen/Mips/longbranch/compact-branches-long-branch.ll Mon Nov 20 07:59:18 2017
@@ -0,0 +1,154 @@
+; RUN: llc < %s -march=mips -mcpu=mips32r6 -force-mips-long-branch | FileCheck %s
+
+; Check that when MIPS32R6 with the static relocation model with the usage of
+; long branches, that there is a nop between any compact branch and the static
+; relocation method of expanding branches. Previously, it could result in 'j'
+; following a b(ne|eq)zc, which would raise a reserved instruction exception.
+
+declare i32 @f(i32)
+
+declare i32 @g()
+
+; CHECK-LABEL: test1:
+; CHECK:       bnezc
+; CHECK-NEXT:  nop
+
+define i32 @test1(i32 %a) {
+entry:
+  %0 = icmp eq i32 %a, 0
+  br i1 %0, label %cond.true, label %cond.false
+cond.true:
+  %1 = call i32 @f(i32 %a)
+  ret i32 %1
+cond.false:
+  %2 = call i32 @g()
+  ret i32 %2
+}
+
+; CHECK-LABEL: test2:
+; CHECK:       bgezc
+; CHECK-NEXT:  nop
+
+define i32 @test2(i32 %a) {
+entry:
+  %0 = icmp sge i32 %a, 0
+  br i1 %0, label %cond.true, label %cond.false
+cond.true:
+  %1 = call i32 @f(i32 %a)
+  ret i32 %1
+cond.false:
+  %2 = call i32 @g()
+  ret i32 %2
+}
+
+; CHECK-LABEL: test3:
+; CHECK:       blezc
+; CHECK-NEXT:  nop
+
+define i32 @test3(i32 %a) {
+entry:
+  %0 = icmp sle i32 %a, 0
+  br i1 %0, label %cond.true, label %cond.false
+cond.true:
+  %1 = call i32 @f(i32 %a)
+  ret i32 %1
+cond.false:
+  %2 = call i32 @g()
+  ret i32 %2
+}
+
+; CHECK-LABEL: test4:
+; CHECK:       bgtzc
+; CHECK-NEXT:  nop
+
+define i32 @test4(i32 %a) {
+entry:
+  %0 = icmp sgt i32 %a, 0
+  br i1 %0, label %cond.true, label %cond.false
+cond.true:
+  %1 = call i32 @f(i32 %a)
+  ret i32 %1
+cond.false:
+  %2 = call i32 @g()
+  ret i32 %2
+}
+
+; CHECK-LABEL: test5:
+; CHECK:       bgezc
+; CHECK-NEXT:  nop
+
+define i32 @test5(i32 %a) {
+entry:
+  %0 = icmp slt i32 %a, 0
+  br i1 %0, label %cond.true, label %cond.false
+cond.true:
+  %1 = call i32 @f(i32 %a)
+  ret i32 %1
+cond.false:
+  %2 = call i32 @g()
+  ret i32 %2
+}
+
+; CHECK-LABEL: test6:
+; CHECK:       bnezc
+; CHECK-NEXT:  nop
+
+define i32 @test6(i32 %a, i32 %b) {
+entry:
+  %0 = icmp ugt i32 %a, %b
+  br i1 %0, label %cond.true, label %cond.false
+cond.true:
+  %1 = call i32 @f(i32 %a)
+  ret i32 %1
+cond.false:
+  %2 = call i32 @g()
+  ret i32 %2
+}
+
+; CHECK-LABEL: test7:
+; CHECK:       beqzc
+; CHECK-NEXT:  nop
+
+define i32 @test7(i32 %a, i32 %b) {
+entry:
+  %0 = icmp uge i32 %a, %b
+  br i1 %0, label %cond.true, label %cond.false
+cond.true:
+  %1 = call i32 @f(i32 %a)
+  ret i32 %1
+cond.false:
+  %2 = call i32 @g()
+  ret i32 %2
+}
+
+; CHECK-LABEL: test8:
+; CHECK:       bnezc
+; CHECK-NEXT:  nop
+
+define i32 @test8(i32 %a, i32 %b) {
+entry:
+  %0 = icmp ult i32 %a, %b
+  br i1 %0, label %cond.true, label %cond.false
+cond.true:
+  %1 = call i32 @f(i32 %a)
+  ret i32 %1
+cond.false:
+  %2 = call i32 @g()
+  ret i32 %2
+}
+
+; CHECK-LABEL: test9:
+; CHECK:       beqzc
+; CHECK-NEXT:  nop
+
+define i32 @test9(i32 %a, i32 %b) {
+entry:
+  %0 = icmp ule i32 %a, %b
+  br i1 %0, label %cond.true, label %cond.false
+cond.true:
+  %1 = call i32 @f(i32 %a)
+  ret i32 %1
+cond.false:
+  %2 = call i32 @g()
+  ret i32 %2
+}




More information about the llvm-commits mailing list