[PATCH] D16290: [mips] Optimize materialization of i64 constants.

[Daniel Sanders via llvm-commits]

dsanders requested changes to this revision.
This revision now requires changes to proceed.

================
Comment at: lib/Target/Mips/MipsInstrInfo.td:2056
@@ -2054,3 +2055,3 @@
 // Arbitrary immediates
-def : MipsPat<(i32 imm:$imm),
-          (ORi (LUi (HI16 imm:$imm)), (LO16 imm:$imm))>;
+def : MipsPat<(VT imm:$imm), (ORiOp (LUiOp (HI16 imm:$imm)), (LO16 imm:$imm))>;
+}
----------------
The bug is probably the use of 'imm' here. I think you want immSExt32.

================
Comment at: test/CodeGen/Mips/cmov.ll:499-500
@@ -506,4 +498,4 @@
 
-; 64-DAG: daddiu $[[R0:[0-9]+]], ${{[0-9]+}}, 32766
-; 64-DAG: slt $[[R1:[0-9]+]], $[[R0]], $4
-; 64-DAG: ori $2, $[[R1]], 4
+; 64-DAG: lui $[[R0:[0-9]+]], 65535
+; 64-DAG: ori $[[R1:[0-9]+]], $[[R0]], 32766
+; 64-DAG: slt $[[R2:[0-9]+]], $[[R1]], $4
----------------
This constant now takes two instructions to materialize but it used to only take one.

================
Comment at: test/CodeGen/Mips/load-store-left-right.ll:157-159
@@ -156,7 +156,5 @@
 ; MIPS64-EL-DAG: lwr $[[R0]], 0($[[R1]])
-; MIPS64-EL-DAG: daddiu $[[R2:[0-9]+]], $zero, 1
-; MIPS64-EL-DAG: dsll   $[[R3:[0-9]+]], $[[R2]], 32
-; MIPS64-EL-DAG: daddiu $[[R4:[0-9]+]], $[[R3]], -1
-; MIPS64-EL-DAG: and    ${{[0-9]+}}, $[[R0]], $[[R4]]
-
+; MIPS64-EL-DAG: lui $[[R1:[0-9]+]], 65535
+; MIPS64-EL-DAG: ori $[[R2:[0-9]+]], $[[R1]], 65535
+; MIPS64-EL-DAG: and    ${{[0-9]+}}, $[[R0]], $[[R2]]
 ; MIPS64-EB:     lwl $[[R0:[0-9]+]], 0($[[R1:[0-9]+]])
----------------
This isn't the same constant as the previous code.
New: 0xffff_ffff_ffff_ffff
Old: 0x0000_0000_ffff_ffff

================
Comment at: test/MC/Mips/sext_64_32.ll:18-20
@@ -14,3 +17,5 @@
 
-define i64 @foo_2(i32 %ival_2) nounwind readnone {
+; CHECK: lui $[[R0:[0-9]+]], 65535
+; CHECK: ori $[[R1:[0-9]+]], $[[R0]], 65535
+; CHECK: and $2, $4, $[[R1]]
 entry:
----------------
This is a nop now because the mask is 0xffff_ffff_ffff_ffff which is the case because lui is sign-extended. It's not clear from the test but I suspect it used to be 0x0000_0000_ffff_ffff which is best done with the dsll32/dsrl32 pair the old test is hinting at.


http://reviews.llvm.org/D16290