RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-23 11:13:28 +01:00
Code Issues Projects Releases Wiki Activity
283f599fca
llvm-mirror/test/CodeGen/PowerPC/sms-cpy-1.ll

114 lines
3.5 KiB
LLVM
Raw Normal View History

[MachinePipeliner] Avoid indeterminate order in FuncUnitSorter Summary: This is exposed by adding a new testcase in PowerPC in https://reviews.llvm.org/rL367732 The testcase got different output on different platform, hence breaking buildbots. The problem is that we get differnt FuncUnitOrder when calculateResMII. The root cause is: 1. Two MachineInstr might get SAME priority(MFUsx) from minFuncUnits. 2. Current comparison operator() will return `MFUs1 > MFUs2`. 3. We use iterators for MachineInstr, so the input to FuncUnitSorter might be different on differnt platform due to the iterator nature. So for two MI with same MFU, their order is actually depends on the iterator order, which is platform (implemtation) dependent. This is risky, and may cause cross-compiling problems. The fix is to check make sure we assign a determine order when they are equal. Reviewers: bcahoon, hfinkel, jmolloy Subscribers: nemanjai, hiraditya, MaskRay, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65992 llvm-svn: 368441
2019-08-09 16:10:57 +02:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
; RUN: llc < %s -mtriple=powerpc64le-unknown-linux-gnu -verify-machineinstrs\
; RUN: -mcpu=pwr9 --ppc-enable-pipeliner 2>&1 | FileCheck %s
@.str.28 = external unnamed_addr constant [69 x i8], align 1
[PowerPC][NFC] Avoid checking non-relevant .cfi instructions Summary: This is brought up in https://reviews.llvm.org/D64662?id=209923#inline-599490 CFI information are non-relevant to quite some testcases, we should get rid of checking them when its unecessary. This patch avoid generating cfi info in testcases that are not testing prolog/epilog or exception handling. Reviewers: kbarton, hfinkel, nemanjai, #powerpc Reviewed By: hfinkel Subscribers: MaskRay, shchenz, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67016 llvm-svn: 370505
2019-08-30 21:24:25 +02:00
define void @print_res() nounwind {
[MachinePipeliner] Avoid indeterminate order in FuncUnitSorter Summary: This is exposed by adding a new testcase in PowerPC in https://reviews.llvm.org/rL367732 The testcase got different output on different platform, hence breaking buildbots. The problem is that we get differnt FuncUnitOrder when calculateResMII. The root cause is: 1. Two MachineInstr might get SAME priority(MFUsx) from minFuncUnits. 2. Current comparison operator() will return `MFUs1 > MFUs2`. 3. We use iterators for MachineInstr, so the input to FuncUnitSorter might be different on differnt platform due to the iterator nature. So for two MI with same MFU, their order is actually depends on the iterator order, which is platform (implemtation) dependent. This is risky, and may cause cross-compiling problems. The fix is to check make sure we assign a determine order when they are equal. Reviewers: bcahoon, hfinkel, jmolloy Subscribers: nemanjai, hiraditya, MaskRay, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65992 llvm-svn: 368441
2019-08-09 16:10:57 +02:00
; CHECK-LABEL: print_res:
; CHECK: # %bb.0:
; CHECK-NEXT: mflr 0
; CHECK-NEXT: std 0, 16(1)
; CHECK-NEXT: stdu 1, -128(1)
; CHECK-NEXT: lwz 3, 0(3)
; CHECK-NEXT: addi 3, 3, -1
; CHECK-NEXT: clrldi 4, 3, 32
[PowerPC] Ignore implicit register operands for MCInst Summary: When doing the conversion: MachineInst -> MCInst, we should ignore the implicit operands, it will expose more opportunity for InstiAlias. Reviewed By: steven.zhang Differential Revision: https://reviews.llvm.org/D77118
2020-04-16 18:22:43 +02:00
; CHECK-NEXT: cmplwi 3, 1
[MachinePipeliner] Avoid indeterminate order in FuncUnitSorter Summary: This is exposed by adding a new testcase in PowerPC in https://reviews.llvm.org/rL367732 The testcase got different output on different platform, hence breaking buildbots. The problem is that we get differnt FuncUnitOrder when calculateResMII. The root cause is: 1. Two MachineInstr might get SAME priority(MFUsx) from minFuncUnits. 2. Current comparison operator() will return `MFUs1 > MFUs2`. 3. We use iterators for MachineInstr, so the input to FuncUnitSorter might be different on differnt platform due to the iterator nature. So for two MI with same MFU, their order is actually depends on the iterator order, which is platform (implemtation) dependent. This is risky, and may cause cross-compiling problems. The fix is to check make sure we assign a determine order when they are equal. Reviewers: bcahoon, hfinkel, jmolloy Subscribers: nemanjai, hiraditya, MaskRay, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65992 llvm-svn: 368441
2019-08-09 16:10:57 +02:00
; CHECK-NEXT: li 3, 1
[PowerPC] Add some InstAlias definitions Summary: This patch add the InstAlias definitions for below instructions. ADDI ADDIS ADDI8 ADDIS8 RLWINM8 ISEL ISEL8 OR OR_rec ORI ORI8 XORI8 CNTLZW8 CNTLZW8_rec TEND TSR RFEBB NOR NOR_rec MTCRF SUBF SUBF_rec SUBFC SUBFC_rec RLDICL_32_64 TW Reviewed By: steven.zhang Differential Revision: https://reviews.llvm.org/D77559
2020-05-24 16:05:28 +02:00
; CHECK-NEXT: iselgt 3, 4, 3
[MachinePipeliner] Avoid indeterminate order in FuncUnitSorter Summary: This is exposed by adding a new testcase in PowerPC in https://reviews.llvm.org/rL367732 The testcase got different output on different platform, hence breaking buildbots. The problem is that we get differnt FuncUnitOrder when calculateResMII. The root cause is: 1. Two MachineInstr might get SAME priority(MFUsx) from minFuncUnits. 2. Current comparison operator() will return `MFUs1 > MFUs2`. 3. We use iterators for MachineInstr, so the input to FuncUnitSorter might be different on differnt platform due to the iterator nature. So for two MI with same MFU, their order is actually depends on the iterator order, which is platform (implemtation) dependent. This is risky, and may cause cross-compiling problems. The fix is to check make sure we assign a determine order when they are equal. Reviewers: bcahoon, hfinkel, jmolloy Subscribers: nemanjai, hiraditya, MaskRay, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65992 llvm-svn: 368441
2019-08-09 16:10:57 +02:00
; CHECK-NEXT: li 4, 2
; CHECK-NEXT: addi 3, 3, -1
; CHECK-NEXT: cmpldi 3, 2
[PowerPC] Add some InstAlias definitions Summary: This patch add the InstAlias definitions for below instructions. ADDI ADDIS ADDI8 ADDIS8 RLWINM8 ISEL ISEL8 OR OR_rec ORI ORI8 XORI8 CNTLZW8 CNTLZW8_rec TEND TSR RFEBB NOR NOR_rec MTCRF SUBF SUBF_rec SUBFC SUBFC_rec RLDICL_32_64 TW Reviewed By: steven.zhang Differential Revision: https://reviews.llvm.org/D77559
2020-05-24 16:05:28 +02:00
; CHECK-NEXT: isellt 3, 3, 4
[MachinePipeliner] Avoid indeterminate order in FuncUnitSorter Summary: This is exposed by adding a new testcase in PowerPC in https://reviews.llvm.org/rL367732 The testcase got different output on different platform, hence breaking buildbots. The problem is that we get differnt FuncUnitOrder when calculateResMII. The root cause is: 1. Two MachineInstr might get SAME priority(MFUsx) from minFuncUnits. 2. Current comparison operator() will return `MFUs1 > MFUs2`. 3. We use iterators for MachineInstr, so the input to FuncUnitSorter might be different on differnt platform due to the iterator nature. So for two MI with same MFU, their order is actually depends on the iterator order, which is platform (implemtation) dependent. This is risky, and may cause cross-compiling problems. The fix is to check make sure we assign a determine order when they are equal. Reviewers: bcahoon, hfinkel, jmolloy Subscribers: nemanjai, hiraditya, MaskRay, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65992 llvm-svn: 368441
2019-08-09 16:10:57 +02:00
; CHECK-NEXT: li 4, 0
; CHECK-NEXT: addi 3, 3, 1
; CHECK-NEXT: mtctr 3
; CHECK-NEXT: li 3, 1
[Power9] Add addi post-ra scheduling heuristic The instruction addi is usually used to post increase the loop indvar, which looks like this: label_X: load x, base(i) ... y = op x ... i = addi i, 1 goto label_X However, for PowerPC, if there are too many vsx instructions that between y = op x and i = addi i, 1, it will use all the hw resource that block the execution of i = addi, i, 1, which result in the stall of the load instruction in next iteration. So, a heuristic is added to move the addi as early as possible to have the load hide the latency of vsx instructions, if other heuristic didn't apply to avoid the starve. Reviewed By: jji Differential Revision: https://reviews.llvm.org/D80269
2020-06-08 03:31:07 +02:00
; CHECK-NEXT: li 7, -1
; CHECK-NEXT: li 5, 0
; CHECK-NEXT: lbz 5, 0(5)
[MachinePipeliner] Avoid indeterminate order in FuncUnitSorter Summary: This is exposed by adding a new testcase in PowerPC in https://reviews.llvm.org/rL367732 The testcase got different output on different platform, hence breaking buildbots. The problem is that we get differnt FuncUnitOrder when calculateResMII. The root cause is: 1. Two MachineInstr might get SAME priority(MFUsx) from minFuncUnits. 2. Current comparison operator() will return `MFUs1 > MFUs2`. 3. We use iterators for MachineInstr, so the input to FuncUnitSorter might be different on differnt platform due to the iterator nature. So for two MI with same MFU, their order is actually depends on the iterator order, which is platform (implemtation) dependent. This is risky, and may cause cross-compiling problems. The fix is to check make sure we assign a determine order when they are equal. Reviewers: bcahoon, hfinkel, jmolloy Subscribers: nemanjai, hiraditya, MaskRay, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65992 llvm-svn: 368441
2019-08-09 16:10:57 +02:00
; CHECK-NEXT: bdz .LBB0_6
; CHECK-NEXT: # %bb.1:
[Power9] Add addi post-ra scheduling heuristic The instruction addi is usually used to post increase the loop indvar, which looks like this: label_X: load x, base(i) ... y = op x ... i = addi i, 1 goto label_X However, for PowerPC, if there are too many vsx instructions that between y = op x and i = addi i, 1, it will use all the hw resource that block the execution of i = addi, i, 1, which result in the stall of the load instruction in next iteration. So, a heuristic is added to move the addi as early as possible to have the load hide the latency of vsx instructions, if other heuristic didn't apply to avoid the starve. Reviewed By: jji Differential Revision: https://reviews.llvm.org/D80269
2020-06-08 03:31:07 +02:00
; CHECK-NEXT: addi 3, 3, 1
; CHECK-NEXT: addi 8, 7, -1
[MachinePipeliner] Avoid indeterminate order in FuncUnitSorter Summary: This is exposed by adding a new testcase in PowerPC in https://reviews.llvm.org/rL367732 The testcase got different output on different platform, hence breaking buildbots. The problem is that we get differnt FuncUnitOrder when calculateResMII. The root cause is: 1. Two MachineInstr might get SAME priority(MFUsx) from minFuncUnits. 2. Current comparison operator() will return `MFUs1 > MFUs2`. 3. We use iterators for MachineInstr, so the input to FuncUnitSorter might be different on differnt platform due to the iterator nature. So for two MI with same MFU, their order is actually depends on the iterator order, which is platform (implemtation) dependent. This is risky, and may cause cross-compiling problems. The fix is to check make sure we assign a determine order when they are equal. Reviewers: bcahoon, hfinkel, jmolloy Subscribers: nemanjai, hiraditya, MaskRay, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65992 llvm-svn: 368441
2019-08-09 16:10:57 +02:00
; CHECK-NEXT: xori 6, 5, 84
; CHECK-NEXT: clrldi 5, 7, 32
; CHECK-NEXT: lbz 5, 0(5)
; CHECK-NEXT: bdz .LBB0_5
; CHECK-NEXT: # %bb.2:
[Power9] Add addi post-ra scheduling heuristic The instruction addi is usually used to post increase the loop indvar, which looks like this: label_X: load x, base(i) ... y = op x ... i = addi i, 1 goto label_X However, for PowerPC, if there are too many vsx instructions that between y = op x and i = addi i, 1, it will use all the hw resource that block the execution of i = addi, i, 1, which result in the stall of the load instruction in next iteration. So, a heuristic is added to move the addi as early as possible to have the load hide the latency of vsx instructions, if other heuristic didn't apply to avoid the starve. Reviewed By: jji Differential Revision: https://reviews.llvm.org/D80269
2020-06-08 03:31:07 +02:00
; CHECK-NEXT: addi 3, 3, 1
[MachinePipeliner] Avoid indeterminate order in FuncUnitSorter Summary: This is exposed by adding a new testcase in PowerPC in https://reviews.llvm.org/rL367732 The testcase got different output on different platform, hence breaking buildbots. The problem is that we get differnt FuncUnitOrder when calculateResMII. The root cause is: 1. Two MachineInstr might get SAME priority(MFUsx) from minFuncUnits. 2. Current comparison operator() will return `MFUs1 > MFUs2`. 3. We use iterators for MachineInstr, so the input to FuncUnitSorter might be different on differnt platform due to the iterator nature. So for two MI with same MFU, their order is actually depends on the iterator order, which is platform (implemtation) dependent. This is risky, and may cause cross-compiling problems. The fix is to check make sure we assign a determine order when they are equal. Reviewers: bcahoon, hfinkel, jmolloy Subscribers: nemanjai, hiraditya, MaskRay, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65992 llvm-svn: 368441
2019-08-09 16:10:57 +02:00
; CHECK-NEXT: cntlzw 6, 6
; CHECK-NEXT: srwi 7, 6, 5
; CHECK-NEXT: xori 6, 5, 84
; CHECK-NEXT: clrldi 5, 8, 32
; CHECK-NEXT: addi 8, 8, -1
; CHECK-NEXT: lbz 5, 0(5)
; CHECK-NEXT: bdz .LBB0_4
[PowerPC] Add some InstAlias definitions Summary: This patch add the InstAlias definitions for below instructions. ADDI ADDIS ADDI8 ADDIS8 RLWINM8 ISEL ISEL8 OR OR_rec ORI ORI8 XORI8 CNTLZW8 CNTLZW8_rec TEND TSR RFEBB NOR NOR_rec MTCRF SUBF SUBF_rec SUBFC SUBFC_rec RLDICL_32_64 TW Reviewed By: steven.zhang Differential Revision: https://reviews.llvm.org/D77559
2020-05-24 16:05:28 +02:00
; CHECK-NEXT: .LBB0_3:
[Power9] Add addi post-ra scheduling heuristic The instruction addi is usually used to post increase the loop indvar, which looks like this: label_X: load x, base(i) ... y = op x ... i = addi i, 1 goto label_X However, for PowerPC, if there are too many vsx instructions that between y = op x and i = addi i, 1, it will use all the hw resource that block the execution of i = addi, i, 1, which result in the stall of the load instruction in next iteration. So, a heuristic is added to move the addi as early as possible to have the load hide the latency of vsx instructions, if other heuristic didn't apply to avoid the starve. Reviewed By: jji Differential Revision: https://reviews.llvm.org/D80269
2020-06-08 03:31:07 +02:00
; CHECK-NEXT: addi 3, 3, 1
[MachinePipeliner] Avoid indeterminate order in FuncUnitSorter Summary: This is exposed by adding a new testcase in PowerPC in https://reviews.llvm.org/rL367732 The testcase got different output on different platform, hence breaking buildbots. The problem is that we get differnt FuncUnitOrder when calculateResMII. The root cause is: 1. Two MachineInstr might get SAME priority(MFUsx) from minFuncUnits. 2. Current comparison operator() will return `MFUs1 > MFUs2`. 3. We use iterators for MachineInstr, so the input to FuncUnitSorter might be different on differnt platform due to the iterator nature. So for two MI with same MFU, their order is actually depends on the iterator order, which is platform (implemtation) dependent. This is risky, and may cause cross-compiling problems. The fix is to check make sure we assign a determine order when they are equal. Reviewers: bcahoon, hfinkel, jmolloy Subscribers: nemanjai, hiraditya, MaskRay, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65992 llvm-svn: 368441
2019-08-09 16:10:57 +02:00
; CHECK-NEXT: clrldi 10, 8, 32
[Power9] Add addi post-ra scheduling heuristic The instruction addi is usually used to post increase the loop indvar, which looks like this: label_X: load x, base(i) ... y = op x ... i = addi i, 1 goto label_X However, for PowerPC, if there are too many vsx instructions that between y = op x and i = addi i, 1, it will use all the hw resource that block the execution of i = addi, i, 1, which result in the stall of the load instruction in next iteration. So, a heuristic is added to move the addi as early as possible to have the load hide the latency of vsx instructions, if other heuristic didn't apply to avoid the starve. Reviewed By: jji Differential Revision: https://reviews.llvm.org/D80269
2020-06-08 03:31:07 +02:00
; CHECK-NEXT: addi 8, 8, -1
[MachinePipeliner] Avoid indeterminate order in FuncUnitSorter Summary: This is exposed by adding a new testcase in PowerPC in https://reviews.llvm.org/rL367732 The testcase got different output on different platform, hence breaking buildbots. The problem is that we get differnt FuncUnitOrder when calculateResMII. The root cause is: 1. Two MachineInstr might get SAME priority(MFUsx) from minFuncUnits. 2. Current comparison operator() will return `MFUs1 > MFUs2`. 3. We use iterators for MachineInstr, so the input to FuncUnitSorter might be different on differnt platform due to the iterator nature. So for two MI with same MFU, their order is actually depends on the iterator order, which is platform (implemtation) dependent. This is risky, and may cause cross-compiling problems. The fix is to check make sure we assign a determine order when they are equal. Reviewers: bcahoon, hfinkel, jmolloy Subscribers: nemanjai, hiraditya, MaskRay, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65992 llvm-svn: 368441
2019-08-09 16:10:57 +02:00
; CHECK-NEXT: cntlzw 9, 6
; CHECK-NEXT: xori 6, 5, 84
; CHECK-NEXT: lbz 5, 0(10)
; CHECK-NEXT: add 4, 4, 7
; CHECK-NEXT: srwi 7, 9, 5
; CHECK-NEXT: bdnz .LBB0_3
; CHECK-NEXT: .LBB0_4:
; CHECK-NEXT: add 4, 4, 7
; CHECK-NEXT: .LBB0_5:
; CHECK-NEXT: cntlzw 6, 6
; CHECK-NEXT: srwi 6, 6, 5
; CHECK-NEXT: add 4, 4, 6
; CHECK-NEXT: .LBB0_6:
; CHECK-NEXT: xori 5, 5, 84
; CHECK-NEXT: cntlzw 5, 5
; CHECK-NEXT: clrldi 3, 3, 32
; CHECK-NEXT: std 3, 104(1)
; CHECK-NEXT: addis 3, 2, .LC0@toc@ha
; CHECK-NEXT: ld 3, .LC0@toc@l(3)
; CHECK-NEXT: li 7, 0
; CHECK-NEXT: li 8, 3
; CHECK-NEXT: srwi 5, 5, 5
; CHECK-NEXT: add 4, 4, 5
; CHECK-NEXT: li 5, 0
; CHECK-NEXT: std 5, 120(1)
; CHECK-NEXT: li 5, 3
; CHECK-NEXT: std 5, 96(1)
; CHECK-NEXT: clrldi 6, 4, 32
; CHECK-NEXT: li 4, 3
; CHECK-NEXT: li 5, 0
; CHECK-NEXT: li 10, 0
; CHECK-NEXT: bl printf
; CHECK-NEXT: nop
%1 = load i32, i32* undef, align 4
%2 = add i32 %1, -1
%3 = zext i32 %2 to i64
%4 = zext i32 3 to i64
br label %5
5: ; preds = %5, %0
%6 = phi i64 [ %16, %5 ], [ 0, %0 ]
%7 = phi i32 [ %15, %5 ], [ 0, %0 ]
%8 = trunc i64 %6 to i32
%9 = sub i32 0, %8
%10 = zext i32 %9 to i64
%11 = getelementptr inbounds i8, i8* null, i64 %10
%12 = load i8, i8* %11, align 1
%13 = icmp eq i8 %12, 84
%14 = zext i1 %13 to i32
%15 = add i32 %7, %14
%16 = add nuw nsw i64 %6, 1
%17 = icmp ult i64 %16, %3
%18 = icmp ult i64 %16, %4
%19 = and i1 %18, %17
br i1 %19, label %5, label %20
20: ; preds = %5
%21 = trunc i64 %16 to i32
call void (i8*, ...) @printf(i8* getelementptr inbounds ([69 x i8], [69 x i8]* @.str.28, i64 0, i64 0), i32 zeroext 3, i32 zeroext undef, i32 zeroext %15, i32 zeroext undef, i32 zeroext 3, i8* undef, i32 zeroext undef, i32 zeroext 3, i32 zeroext %21, i8* undef, i32 zeroext undef) #1
unreachable
}
declare void @printf(i8*, ...) local_unnamed_addr #0
Reference in New Issue Copy Permalink