maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/CodeGen/SystemZ/cond-move-01.ll

126 lines
2.8 KiB
LLVM
Raw Normal View History

[SystemZ] Add LOCR and LOCGR llvm-svn: 187113
2013-07-25 17:11:15 +08:00
; Test LOCR and LOCGR.
;
[SystemZ] Improve use of conditional instructions This patch moves formation of LOC-type instructions from (late) IfConversion to the early if-conversion pass, and in some cases additionally creates them directly from select instructions during DAG instruction selection. To make early if-conversion work, the patch implements the canInsertSelect / insertSelect callbacks. It also implements the commuteInstructionImpl and FoldImmediate callbacks to enable generation of the full range of LOC instructions. Finally, the patch adds support for all instructions of the load-store-on-condition-2 facility, which allows using LOC instructions also for high registers. Due to the use of the GRX32 register class to enable high registers, we now also have to handle the cases where there are still no single hardware instructions (conditional move from a low register to a high register or vice versa). These are converted back to a branch sequence after register allocation. Since the expandRAPseudos callback is not allowed to create new basic blocks, this requires a simple new pass, modelled after the ARM/AArch64 ExpandPseudos pass. Overall, this patch causes significantly more LOC-type instructions to be used, and results in a measurable performance improvement. llvm-svn: 288028
2016-11-28 21:34:08 +08:00
; RUN: llc < %s -mtriple=s390x-linux-gnu -mcpu=z196 -verify-machineinstrs | FileCheck %s
;
; Run the test again to make sure it still works the same even
; in the presence of the load-store-on-condition-2 facility.
; RUN: llc < %s -mtriple=s390x-linux-gnu -mcpu=z13 -verify-machineinstrs | FileCheck %s
[SystemZ] Add LOCR and LOCGR llvm-svn: 187113
2013-07-25 17:11:15 +08:00
; Test LOCR.
define i32 @f1(i32 %a, i32 %b, i32 %limit) {
; CHECK-LABEL: f1:
; CHECK: clfi %r4, 42
[SystemZ] Be more careful about inverting CC masks System z branches have a mask to select which of the 4 CC values should cause the branch to be taken. We can invert a branch by inverting the mask. However, not all instructions can produce all 4 CC values, so inverting the branch like this can lead to some oddities. For example, integer comparisons only produce a CC of 0 (equal), 1 (less) or 2 (greater). If an integer EQ is reversed to NE before instruction selection, the branch will test for 1 or 2. If instead the branch is reversed after instruction selection (by inverting the mask), it will test for 1, 2 or 3. Both are correct, but the second isn't really canonical. This patch therefore keeps track of which CC values are possible and uses this when inverting a mask. Although this is mostly cosmestic, it fixes undefined behavior for the CIJNLH in branch-08.ll. Another fix would have been to mask out bit 0 when generating the fused compare and branch, but the point of this patch is that we shouldn't need to do that in the first place. The patch also makes it easier to reuse CC results from other instructions. llvm-svn: 187495
2013-07-31 20:30:20 +08:00
; CHECK: locrhe %r2, %r3
[SystemZ] Add LOCR and LOCGR llvm-svn: 187113
2013-07-25 17:11:15 +08:00
; CHECK: br %r14
%cond = icmp ult i32 %limit, 42
%res = select i1 %cond, i32 %a, i32 %b
ret i32 %res
}
; Test LOCGR.
define i64 @f2(i64 %a, i64 %b, i64 %limit) {
; CHECK-LABEL: f2:
; CHECK: clgfi %r4, 42
[SystemZ] Be more careful about inverting CC masks System z branches have a mask to select which of the 4 CC values should cause the branch to be taken. We can invert a branch by inverting the mask. However, not all instructions can produce all 4 CC values, so inverting the branch like this can lead to some oddities. For example, integer comparisons only produce a CC of 0 (equal), 1 (less) or 2 (greater). If an integer EQ is reversed to NE before instruction selection, the branch will test for 1 or 2. If instead the branch is reversed after instruction selection (by inverting the mask), it will test for 1, 2 or 3. Both are correct, but the second isn't really canonical. This patch therefore keeps track of which CC values are possible and uses this when inverting a mask. Although this is mostly cosmestic, it fixes undefined behavior for the CIJNLH in branch-08.ll. Another fix would have been to mask out bit 0 when generating the fused compare and branch, but the point of this patch is that we shouldn't need to do that in the first place. The patch also makes it easier to reuse CC results from other instructions. llvm-svn: 187495
2013-07-31 20:30:20 +08:00
; CHECK: locgrhe %r2, %r3
[SystemZ] Add LOCR and LOCGR llvm-svn: 187113
2013-07-25 17:11:15 +08:00
; CHECK: br %r14
%cond = icmp ult i64 %limit, 42
%res = select i1 %cond, i64 %a, i64 %b
ret i64 %res
}
[SystemZ] Be more careful about inverting CC masks System z branches have a mask to select which of the 4 CC values should cause the branch to be taken. We can invert a branch by inverting the mask. However, not all instructions can produce all 4 CC values, so inverting the branch like this can lead to some oddities. For example, integer comparisons only produce a CC of 0 (equal), 1 (less) or 2 (greater). If an integer EQ is reversed to NE before instruction selection, the branch will test for 1 or 2. If instead the branch is reversed after instruction selection (by inverting the mask), it will test for 1, 2 or 3. Both are correct, but the second isn't really canonical. This patch therefore keeps track of which CC values are possible and uses this when inverting a mask. Although this is mostly cosmestic, it fixes undefined behavior for the CIJNLH in branch-08.ll. Another fix would have been to mask out bit 0 when generating the fused compare and branch, but the point of this patch is that we shouldn't need to do that in the first place. The patch also makes it easier to reuse CC results from other instructions. llvm-svn: 187495
2013-07-31 20:30:20 +08:00
; Test LOCR in a case that could use COMPARE AND BRANCH. We prefer using
; LOCR if possible.
define i32 @f3(i32 %a, i32 %b, i32 %limit) {
; CHECK-LABEL: f3:
; CHECK: chi %r4, 42
; CHECK: locrlh %r2, %r3
; CHECK: br %r14
%cond = icmp eq i32 %limit, 42
%res = select i1 %cond, i32 %a, i32 %b
ret i32 %res
}
; ...and again for LOCGR.
define i64 @f4(i64 %a, i64 %b, i64 %limit) {
; CHECK-LABEL: f4:
; CHECK: cghi %r4, 42
; CHECK: locgrlh %r2, %r3
; CHECK: br %r14
%cond = icmp eq i64 %limit, 42
%res = select i1 %cond, i64 %a, i64 %b
ret i64 %res
}
[SystemZ] Improve use of conditional instructions This patch moves formation of LOC-type instructions from (late) IfConversion to the early if-conversion pass, and in some cases additionally creates them directly from select instructions during DAG instruction selection. To make early if-conversion work, the patch implements the canInsertSelect / insertSelect callbacks. It also implements the commuteInstructionImpl and FoldImmediate callbacks to enable generation of the full range of LOC instructions. Finally, the patch adds support for all instructions of the load-store-on-condition-2 facility, which allows using LOC instructions also for high registers. Due to the use of the GRX32 register class to enable high registers, we now also have to handle the cases where there are still no single hardware instructions (conditional move from a low register to a high register or vice versa). These are converted back to a branch sequence after register allocation. Since the expandRAPseudos callback is not allowed to create new basic blocks, this requires a simple new pass, modelled after the ARM/AArch64 ExpandPseudos pass. Overall, this patch causes significantly more LOC-type instructions to be used, and results in a measurable performance improvement. llvm-svn: 288028
2016-11-28 21:34:08 +08:00
; Check that we also get LOCR as a result of early if-conversion.
define i32 @f5(i32 %a, i32 %b, i32 %limit) {
; CHECK-LABEL: f5:
; CHECK: clfi %r4, 41
; CHECK: locrh %r2, %r3
; CHECK: br %r14
entry:
%cond = icmp ult i32 %limit, 42
br i1 %cond, label %if.then, label %return
if.then:
br label %return
return:
%res = phi i32 [ %a, %if.then ], [ %b, %entry ]
ret i32 %res
}
; ... and likewise for LOCGR.
define i64 @f6(i64 %a, i64 %b, i64 %limit) {
; CHECK-LABEL: f6:
; CHECK: clgfi %r4, 41
; CHECK: locgrh %r2, %r3
; CHECK: br %r14
entry:
%cond = icmp ult i64 %limit, 42
br i1 %cond, label %if.then, label %return
if.then:
br label %return
return:
%res = phi i64 [ %a, %if.then ], [ %b, %entry ]
ret i64 %res
}
; Check that inverting the condition works as well.
define i32 @f7(i32 %a, i32 %b, i32 %limit) {
; CHECK-LABEL: f7:
; CHECK: clfi %r4, 41
; CHECK: locrle %r2, %r3
; CHECK: br %r14
entry:
%cond = icmp ult i32 %limit, 42
br i1 %cond, label %if.then, label %return
if.then:
br label %return
return:
%res = phi i32 [ %b, %if.then ], [ %a, %entry ]
ret i32 %res
}
; ... and likewise for LOCGR.
define i64 @f8(i64 %a, i64 %b, i64 %limit) {
; CHECK-LABEL: f8:
; CHECK: clgfi %r4, 41
; CHECK: locgrle %r2, %r3
; CHECK: br %r14
entry:
%cond = icmp ult i64 %limit, 42
br i1 %cond, label %if.then, label %return
if.then:
br label %return
return:
%res = phi i64 [ %b, %if.then ], [ %a, %entry ]
ret i64 %res
}