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/RISCV/stack-store-check.ll

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

325 lines
12 KiB
LLVM
Raw Normal View History

[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
; RUN: llc -mtriple riscv32 -o - %s | FileCheck %s
; This test has been minimized from GCC Torture Suite's regstack-1.c
; and checks that RISCVInstrInfo::storeRegToStackSlot works at the basic
; level.
@U = external local_unnamed_addr global fp128, align 16
@Y1 = external local_unnamed_addr global fp128, align 16
@X = external local_unnamed_addr global fp128, align 16
@Y = external local_unnamed_addr global fp128, align 16
@T = external local_unnamed_addr global fp128, align 16
@S = external local_unnamed_addr global fp128, align 16
define void @main() local_unnamed_addr nounwind {
; CHECK-LABEL: main:
; CHECK: # %bb.0:
; CHECK-NEXT: addi sp, sp, -688
[RISCV][NFC] Regenerate RISCV CodeGen tests Regenerated using: ./llvm/utils/update_llc_test_checks.py -u llvm/test/CodeGen/RISCV/*.ll This has added comments to spill-related instructions and added @plt to some symbols. Differential Revision: https://reviews.llvm.org/D92841
2020-12-10 03:41:19 +08:00
; CHECK-NEXT: sw ra, 684(sp) # 4-byte Folded Spill
; CHECK-NEXT: sw s0, 680(sp) # 4-byte Folded Spill
; CHECK-NEXT: sw s1, 676(sp) # 4-byte Folded Spill
; CHECK-NEXT: sw s2, 672(sp) # 4-byte Folded Spill
; CHECK-NEXT: sw s3, 668(sp) # 4-byte Folded Spill
; CHECK-NEXT: sw s4, 664(sp) # 4-byte Folded Spill
; CHECK-NEXT: sw s5, 660(sp) # 4-byte Folded Spill
; CHECK-NEXT: sw s6, 656(sp) # 4-byte Folded Spill
; CHECK-NEXT: sw s7, 652(sp) # 4-byte Folded Spill
; CHECK-NEXT: sw s8, 648(sp) # 4-byte Folded Spill
; CHECK-NEXT: sw s9, 644(sp) # 4-byte Folded Spill
; CHECK-NEXT: sw s10, 640(sp) # 4-byte Folded Spill
; CHECK-NEXT: sw s11, 636(sp) # 4-byte Folded Spill
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: lui a0, %hi(U)
; CHECK-NEXT: lw s6, %lo(U)(a0)
; CHECK-NEXT: lw s7, %lo(U+4)(a0)
; CHECK-NEXT: lw s8, %lo(U+8)(a0)
RegAllocGreedy: Account for reserved registers in num regs heuristic This simple heuristic uses the estimated live range length combined with the number of registers in the class to switch which heuristic to use. This was taking the raw number of registers in the class, even though not all of them may be available. AMDGPU heavily relies on dynamically reserved numbers of registers based on user attributes to satisfy occupancy constraints, so the raw number is highly misleading. There are still a few problems here. In the original testcase that made me notice this, the live range size is incorrect after the scheduler rearranges instructions, since the instructions don't have the original InstrDist offsets. Additionally, I think it would be more appropriate to use the number of disjointly allocatable registers in the class. For the AMDGPU register tuples, there are a large number of registers in each tuple class, but only a small fraction can actually be allocated at the same time since they all overlap with each other. It seems we do not have a query that corresponds to the number of independently allocatable registers. Relatedly, I'm still debugging some allocation failures where overlapping tuples seem to not be handled correctly. The test changes are mostly noise. There are a handful of x86 tests that look like regressions with an additional spill, and a handful that now avoid a spill. The worst looking regression is likely test/Thumb2/mve-vld4.ll which introduces a few additional spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll shows a massive improvement by completely eliminating a large number of spills inside a loop.
2021-08-22 02:54:51 +08:00
; CHECK-NEXT: lw s2, %lo(U+12)(a0)
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: sw zero, 612(sp)
; CHECK-NEXT: sw zero, 608(sp)
; CHECK-NEXT: sw zero, 604(sp)
; CHECK-NEXT: sw zero, 600(sp)
RegAllocGreedy: Account for reserved registers in num regs heuristic This simple heuristic uses the estimated live range length combined with the number of registers in the class to switch which heuristic to use. This was taking the raw number of registers in the class, even though not all of them may be available. AMDGPU heavily relies on dynamically reserved numbers of registers based on user attributes to satisfy occupancy constraints, so the raw number is highly misleading. There are still a few problems here. In the original testcase that made me notice this, the live range size is incorrect after the scheduler rearranges instructions, since the instructions don't have the original InstrDist offsets. Additionally, I think it would be more appropriate to use the number of disjointly allocatable registers in the class. For the AMDGPU register tuples, there are a large number of registers in each tuple class, but only a small fraction can actually be allocated at the same time since they all overlap with each other. It seems we do not have a query that corresponds to the number of independently allocatable registers. Relatedly, I'm still debugging some allocation failures where overlapping tuples seem to not be handled correctly. The test changes are mostly noise. There are a handful of x86 tests that look like regressions with an additional spill, and a handful that now avoid a spill. The worst looking regression is likely test/Thumb2/mve-vld4.ll which introduces a few additional spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll shows a massive improvement by completely eliminating a large number of spills inside a loop.
2021-08-22 02:54:51 +08:00
; CHECK-NEXT: sw s2, 596(sp)
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: sw s8, 592(sp)
; CHECK-NEXT: sw s7, 588(sp)
; CHECK-NEXT: addi a0, sp, 616
; CHECK-NEXT: addi a1, sp, 600
; CHECK-NEXT: addi a2, sp, 584
; CHECK-NEXT: sw s6, 584(sp)
[RISCV][NFC] Regenerate RISCV CodeGen tests Regenerated using: ./llvm/utils/update_llc_test_checks.py -u llvm/test/CodeGen/RISCV/*.ll This has added comments to spill-related instructions and added @plt to some symbols. Differential Revision: https://reviews.llvm.org/D92841
2020-12-10 03:41:19 +08:00
; CHECK-NEXT: call __subtf3@plt
RegAllocGreedy: Account for reserved registers in num regs heuristic This simple heuristic uses the estimated live range length combined with the number of registers in the class to switch which heuristic to use. This was taking the raw number of registers in the class, even though not all of them may be available. AMDGPU heavily relies on dynamically reserved numbers of registers based on user attributes to satisfy occupancy constraints, so the raw number is highly misleading. There are still a few problems here. In the original testcase that made me notice this, the live range size is incorrect after the scheduler rearranges instructions, since the instructions don't have the original InstrDist offsets. Additionally, I think it would be more appropriate to use the number of disjointly allocatable registers in the class. For the AMDGPU register tuples, there are a large number of registers in each tuple class, but only a small fraction can actually be allocated at the same time since they all overlap with each other. It seems we do not have a query that corresponds to the number of independently allocatable registers. Relatedly, I'm still debugging some allocation failures where overlapping tuples seem to not be handled correctly. The test changes are mostly noise. There are a handful of x86 tests that look like regressions with an additional spill, and a handful that now avoid a spill. The worst looking regression is likely test/Thumb2/mve-vld4.ll which introduces a few additional spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll shows a massive improvement by completely eliminating a large number of spills inside a loop.
2021-08-22 02:54:51 +08:00
; CHECK-NEXT: lw s4, 616(sp)
; CHECK-NEXT: lw s5, 620(sp)
; CHECK-NEXT: lw s3, 624(sp)
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: lw s11, 628(sp)
RegAllocGreedy: Account for reserved registers in num regs heuristic This simple heuristic uses the estimated live range length combined with the number of registers in the class to switch which heuristic to use. This was taking the raw number of registers in the class, even though not all of them may be available. AMDGPU heavily relies on dynamically reserved numbers of registers based on user attributes to satisfy occupancy constraints, so the raw number is highly misleading. There are still a few problems here. In the original testcase that made me notice this, the live range size is incorrect after the scheduler rearranges instructions, since the instructions don't have the original InstrDist offsets. Additionally, I think it would be more appropriate to use the number of disjointly allocatable registers in the class. For the AMDGPU register tuples, there are a large number of registers in each tuple class, but only a small fraction can actually be allocated at the same time since they all overlap with each other. It seems we do not have a query that corresponds to the number of independently allocatable registers. Relatedly, I'm still debugging some allocation failures where overlapping tuples seem to not be handled correctly. The test changes are mostly noise. There are a handful of x86 tests that look like regressions with an additional spill, and a handful that now avoid a spill. The worst looking regression is likely test/Thumb2/mve-vld4.ll which introduces a few additional spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll shows a massive improvement by completely eliminating a large number of spills inside a loop.
2021-08-22 02:54:51 +08:00
; CHECK-NEXT: sw s2, 548(sp)
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: sw s8, 544(sp)
; CHECK-NEXT: sw s7, 540(sp)
; CHECK-NEXT: sw s6, 536(sp)
; CHECK-NEXT: sw s11, 564(sp)
RegAllocGreedy: Account for reserved registers in num regs heuristic This simple heuristic uses the estimated live range length combined with the number of registers in the class to switch which heuristic to use. This was taking the raw number of registers in the class, even though not all of them may be available. AMDGPU heavily relies on dynamically reserved numbers of registers based on user attributes to satisfy occupancy constraints, so the raw number is highly misleading. There are still a few problems here. In the original testcase that made me notice this, the live range size is incorrect after the scheduler rearranges instructions, since the instructions don't have the original InstrDist offsets. Additionally, I think it would be more appropriate to use the number of disjointly allocatable registers in the class. For the AMDGPU register tuples, there are a large number of registers in each tuple class, but only a small fraction can actually be allocated at the same time since they all overlap with each other. It seems we do not have a query that corresponds to the number of independently allocatable registers. Relatedly, I'm still debugging some allocation failures where overlapping tuples seem to not be handled correctly. The test changes are mostly noise. There are a handful of x86 tests that look like regressions with an additional spill, and a handful that now avoid a spill. The worst looking regression is likely test/Thumb2/mve-vld4.ll which introduces a few additional spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll shows a massive improvement by completely eliminating a large number of spills inside a loop.
2021-08-22 02:54:51 +08:00
; CHECK-NEXT: sw s3, 560(sp)
; CHECK-NEXT: sw s5, 556(sp)
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: addi a0, sp, 568
; CHECK-NEXT: addi a1, sp, 552
; CHECK-NEXT: addi a2, sp, 536
RegAllocGreedy: Account for reserved registers in num regs heuristic This simple heuristic uses the estimated live range length combined with the number of registers in the class to switch which heuristic to use. This was taking the raw number of registers in the class, even though not all of them may be available. AMDGPU heavily relies on dynamically reserved numbers of registers based on user attributes to satisfy occupancy constraints, so the raw number is highly misleading. There are still a few problems here. In the original testcase that made me notice this, the live range size is incorrect after the scheduler rearranges instructions, since the instructions don't have the original InstrDist offsets. Additionally, I think it would be more appropriate to use the number of disjointly allocatable registers in the class. For the AMDGPU register tuples, there are a large number of registers in each tuple class, but only a small fraction can actually be allocated at the same time since they all overlap with each other. It seems we do not have a query that corresponds to the number of independently allocatable registers. Relatedly, I'm still debugging some allocation failures where overlapping tuples seem to not be handled correctly. The test changes are mostly noise. There are a handful of x86 tests that look like regressions with an additional spill, and a handful that now avoid a spill. The worst looking regression is likely test/Thumb2/mve-vld4.ll which introduces a few additional spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll shows a massive improvement by completely eliminating a large number of spills inside a loop.
2021-08-22 02:54:51 +08:00
; CHECK-NEXT: sw s4, 552(sp)
[RISCV][NFC] Regenerate RISCV CodeGen tests Regenerated using: ./llvm/utils/update_llc_test_checks.py -u llvm/test/CodeGen/RISCV/*.ll This has added comments to spill-related instructions and added @plt to some symbols. Differential Revision: https://reviews.llvm.org/D92841
2020-12-10 03:41:19 +08:00
; CHECK-NEXT: call __subtf3@plt
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: lw a0, 568(sp)
[RISCV][NFC] Regenerate RISCV CodeGen tests Regenerated using: ./llvm/utils/update_llc_test_checks.py -u llvm/test/CodeGen/RISCV/*.ll This has added comments to spill-related instructions and added @plt to some symbols. Differential Revision: https://reviews.llvm.org/D92841
2020-12-10 03:41:19 +08:00
; CHECK-NEXT: sw a0, 40(sp) # 4-byte Folded Spill
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: lw a0, 572(sp)
[RISCV][NFC] Regenerate RISCV CodeGen tests Regenerated using: ./llvm/utils/update_llc_test_checks.py -u llvm/test/CodeGen/RISCV/*.ll This has added comments to spill-related instructions and added @plt to some symbols. Differential Revision: https://reviews.llvm.org/D92841
2020-12-10 03:41:19 +08:00
; CHECK-NEXT: sw a0, 32(sp) # 4-byte Folded Spill
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: lw a0, 576(sp)
[RISCV][NFC] Regenerate RISCV CodeGen tests Regenerated using: ./llvm/utils/update_llc_test_checks.py -u llvm/test/CodeGen/RISCV/*.ll This has added comments to spill-related instructions and added @plt to some symbols. Differential Revision: https://reviews.llvm.org/D92841
2020-12-10 03:41:19 +08:00
; CHECK-NEXT: sw a0, 24(sp) # 4-byte Folded Spill
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: lw a0, 580(sp)
RegAllocGreedy: Account for reserved registers in num regs heuristic This simple heuristic uses the estimated live range length combined with the number of registers in the class to switch which heuristic to use. This was taking the raw number of registers in the class, even though not all of them may be available. AMDGPU heavily relies on dynamically reserved numbers of registers based on user attributes to satisfy occupancy constraints, so the raw number is highly misleading. There are still a few problems here. In the original testcase that made me notice this, the live range size is incorrect after the scheduler rearranges instructions, since the instructions don't have the original InstrDist offsets. Additionally, I think it would be more appropriate to use the number of disjointly allocatable registers in the class. For the AMDGPU register tuples, there are a large number of registers in each tuple class, but only a small fraction can actually be allocated at the same time since they all overlap with each other. It seems we do not have a query that corresponds to the number of independently allocatable registers. Relatedly, I'm still debugging some allocation failures where overlapping tuples seem to not be handled correctly. The test changes are mostly noise. There are a handful of x86 tests that look like regressions with an additional spill, and a handful that now avoid a spill. The worst looking regression is likely test/Thumb2/mve-vld4.ll which introduces a few additional spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll shows a massive improvement by completely eliminating a large number of spills inside a loop.
2021-08-22 02:54:51 +08:00
; CHECK-NEXT: sw a0, 48(sp) # 4-byte Folded Spill
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: sw zero, 500(sp)
; CHECK-NEXT: sw zero, 496(sp)
; CHECK-NEXT: sw zero, 492(sp)
; CHECK-NEXT: sw zero, 488(sp)
RegAllocGreedy: Account for reserved registers in num regs heuristic This simple heuristic uses the estimated live range length combined with the number of registers in the class to switch which heuristic to use. This was taking the raw number of registers in the class, even though not all of them may be available. AMDGPU heavily relies on dynamically reserved numbers of registers based on user attributes to satisfy occupancy constraints, so the raw number is highly misleading. There are still a few problems here. In the original testcase that made me notice this, the live range size is incorrect after the scheduler rearranges instructions, since the instructions don't have the original InstrDist offsets. Additionally, I think it would be more appropriate to use the number of disjointly allocatable registers in the class. For the AMDGPU register tuples, there are a large number of registers in each tuple class, but only a small fraction can actually be allocated at the same time since they all overlap with each other. It seems we do not have a query that corresponds to the number of independently allocatable registers. Relatedly, I'm still debugging some allocation failures where overlapping tuples seem to not be handled correctly. The test changes are mostly noise. There are a handful of x86 tests that look like regressions with an additional spill, and a handful that now avoid a spill. The worst looking regression is likely test/Thumb2/mve-vld4.ll which introduces a few additional spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll shows a massive improvement by completely eliminating a large number of spills inside a loop.
2021-08-22 02:54:51 +08:00
; CHECK-NEXT: sw s2, 516(sp)
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: sw s8, 512(sp)
; CHECK-NEXT: sw s7, 508(sp)
; CHECK-NEXT: addi a0, sp, 520
; CHECK-NEXT: addi a1, sp, 504
; CHECK-NEXT: addi a2, sp, 488
; CHECK-NEXT: sw s6, 504(sp)
[RISCV][NFC] Regenerate RISCV CodeGen tests Regenerated using: ./llvm/utils/update_llc_test_checks.py -u llvm/test/CodeGen/RISCV/*.ll This has added comments to spill-related instructions and added @plt to some symbols. Differential Revision: https://reviews.llvm.org/D92841
2020-12-10 03:41:19 +08:00
; CHECK-NEXT: call __addtf3@plt
RegAllocGreedy: Account for reserved registers in num regs heuristic This simple heuristic uses the estimated live range length combined with the number of registers in the class to switch which heuristic to use. This was taking the raw number of registers in the class, even though not all of them may be available. AMDGPU heavily relies on dynamically reserved numbers of registers based on user attributes to satisfy occupancy constraints, so the raw number is highly misleading. There are still a few problems here. In the original testcase that made me notice this, the live range size is incorrect after the scheduler rearranges instructions, since the instructions don't have the original InstrDist offsets. Additionally, I think it would be more appropriate to use the number of disjointly allocatable registers in the class. For the AMDGPU register tuples, there are a large number of registers in each tuple class, but only a small fraction can actually be allocated at the same time since they all overlap with each other. It seems we do not have a query that corresponds to the number of independently allocatable registers. Relatedly, I'm still debugging some allocation failures where overlapping tuples seem to not be handled correctly. The test changes are mostly noise. There are a handful of x86 tests that look like regressions with an additional spill, and a handful that now avoid a spill. The worst looking regression is likely test/Thumb2/mve-vld4.ll which introduces a few additional spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll shows a massive improvement by completely eliminating a large number of spills inside a loop.
2021-08-22 02:54:51 +08:00
; CHECK-NEXT: lw s9, 520(sp)
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: lw s10, 524(sp)
RegAllocGreedy: Account for reserved registers in num regs heuristic This simple heuristic uses the estimated live range length combined with the number of registers in the class to switch which heuristic to use. This was taking the raw number of registers in the class, even though not all of them may be available. AMDGPU heavily relies on dynamically reserved numbers of registers based on user attributes to satisfy occupancy constraints, so the raw number is highly misleading. There are still a few problems here. In the original testcase that made me notice this, the live range size is incorrect after the scheduler rearranges instructions, since the instructions don't have the original InstrDist offsets. Additionally, I think it would be more appropriate to use the number of disjointly allocatable registers in the class. For the AMDGPU register tuples, there are a large number of registers in each tuple class, but only a small fraction can actually be allocated at the same time since they all overlap with each other. It seems we do not have a query that corresponds to the number of independently allocatable registers. Relatedly, I'm still debugging some allocation failures where overlapping tuples seem to not be handled correctly. The test changes are mostly noise. There are a handful of x86 tests that look like regressions with an additional spill, and a handful that now avoid a spill. The worst looking regression is likely test/Thumb2/mve-vld4.ll which introduces a few additional spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll shows a massive improvement by completely eliminating a large number of spills inside a loop.
2021-08-22 02:54:51 +08:00
; CHECK-NEXT: lw s0, 528(sp)
; CHECK-NEXT: sw s0, 20(sp) # 4-byte Folded Spill
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: lw s1, 532(sp)
RegAllocGreedy: Account for reserved registers in num regs heuristic This simple heuristic uses the estimated live range length combined with the number of registers in the class to switch which heuristic to use. This was taking the raw number of registers in the class, even though not all of them may be available. AMDGPU heavily relies on dynamically reserved numbers of registers based on user attributes to satisfy occupancy constraints, so the raw number is highly misleading. There are still a few problems here. In the original testcase that made me notice this, the live range size is incorrect after the scheduler rearranges instructions, since the instructions don't have the original InstrDist offsets. Additionally, I think it would be more appropriate to use the number of disjointly allocatable registers in the class. For the AMDGPU register tuples, there are a large number of registers in each tuple class, but only a small fraction can actually be allocated at the same time since they all overlap with each other. It seems we do not have a query that corresponds to the number of independently allocatable registers. Relatedly, I'm still debugging some allocation failures where overlapping tuples seem to not be handled correctly. The test changes are mostly noise. There are a handful of x86 tests that look like regressions with an additional spill, and a handful that now avoid a spill. The worst looking regression is likely test/Thumb2/mve-vld4.ll which introduces a few additional spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll shows a massive improvement by completely eliminating a large number of spills inside a loop.
2021-08-22 02:54:51 +08:00
; CHECK-NEXT: sw s1, 16(sp) # 4-byte Folded Spill
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: lui a0, %hi(Y1)
; CHECK-NEXT: lw a1, %lo(Y1)(a0)
RegAllocGreedy: Account for reserved registers in num regs heuristic This simple heuristic uses the estimated live range length combined with the number of registers in the class to switch which heuristic to use. This was taking the raw number of registers in the class, even though not all of them may be available. AMDGPU heavily relies on dynamically reserved numbers of registers based on user attributes to satisfy occupancy constraints, so the raw number is highly misleading. There are still a few problems here. In the original testcase that made me notice this, the live range size is incorrect after the scheduler rearranges instructions, since the instructions don't have the original InstrDist offsets. Additionally, I think it would be more appropriate to use the number of disjointly allocatable registers in the class. For the AMDGPU register tuples, there are a large number of registers in each tuple class, but only a small fraction can actually be allocated at the same time since they all overlap with each other. It seems we do not have a query that corresponds to the number of independently allocatable registers. Relatedly, I'm still debugging some allocation failures where overlapping tuples seem to not be handled correctly. The test changes are mostly noise. There are a handful of x86 tests that look like regressions with an additional spill, and a handful that now avoid a spill. The worst looking regression is likely test/Thumb2/mve-vld4.ll which introduces a few additional spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll shows a massive improvement by completely eliminating a large number of spills inside a loop.
2021-08-22 02:54:51 +08:00
; CHECK-NEXT: sw a1, 52(sp) # 4-byte Folded Spill
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: lw a2, %lo(Y1+4)(a0)
RegAllocGreedy: Account for reserved registers in num regs heuristic This simple heuristic uses the estimated live range length combined with the number of registers in the class to switch which heuristic to use. This was taking the raw number of registers in the class, even though not all of them may be available. AMDGPU heavily relies on dynamically reserved numbers of registers based on user attributes to satisfy occupancy constraints, so the raw number is highly misleading. There are still a few problems here. In the original testcase that made me notice this, the live range size is incorrect after the scheduler rearranges instructions, since the instructions don't have the original InstrDist offsets. Additionally, I think it would be more appropriate to use the number of disjointly allocatable registers in the class. For the AMDGPU register tuples, there are a large number of registers in each tuple class, but only a small fraction can actually be allocated at the same time since they all overlap with each other. It seems we do not have a query that corresponds to the number of independently allocatable registers. Relatedly, I'm still debugging some allocation failures where overlapping tuples seem to not be handled correctly. The test changes are mostly noise. There are a handful of x86 tests that look like regressions with an additional spill, and a handful that now avoid a spill. The worst looking regression is likely test/Thumb2/mve-vld4.ll which introduces a few additional spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll shows a massive improvement by completely eliminating a large number of spills inside a loop.
2021-08-22 02:54:51 +08:00
; CHECK-NEXT: sw a2, 12(sp) # 4-byte Folded Spill
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: lw a3, %lo(Y1+8)(a0)
RegAllocGreedy: Account for reserved registers in num regs heuristic This simple heuristic uses the estimated live range length combined with the number of registers in the class to switch which heuristic to use. This was taking the raw number of registers in the class, even though not all of them may be available. AMDGPU heavily relies on dynamically reserved numbers of registers based on user attributes to satisfy occupancy constraints, so the raw number is highly misleading. There are still a few problems here. In the original testcase that made me notice this, the live range size is incorrect after the scheduler rearranges instructions, since the instructions don't have the original InstrDist offsets. Additionally, I think it would be more appropriate to use the number of disjointly allocatable registers in the class. For the AMDGPU register tuples, there are a large number of registers in each tuple class, but only a small fraction can actually be allocated at the same time since they all overlap with each other. It seems we do not have a query that corresponds to the number of independently allocatable registers. Relatedly, I'm still debugging some allocation failures where overlapping tuples seem to not be handled correctly. The test changes are mostly noise. There are a handful of x86 tests that look like regressions with an additional spill, and a handful that now avoid a spill. The worst looking regression is likely test/Thumb2/mve-vld4.ll which introduces a few additional spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll shows a massive improvement by completely eliminating a large number of spills inside a loop.
2021-08-22 02:54:51 +08:00
; CHECK-NEXT: sw a3, 8(sp) # 4-byte Folded Spill
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: lw a0, %lo(Y1+12)(a0)
RegAllocGreedy: Account for reserved registers in num regs heuristic This simple heuristic uses the estimated live range length combined with the number of registers in the class to switch which heuristic to use. This was taking the raw number of registers in the class, even though not all of them may be available. AMDGPU heavily relies on dynamically reserved numbers of registers based on user attributes to satisfy occupancy constraints, so the raw number is highly misleading. There are still a few problems here. In the original testcase that made me notice this, the live range size is incorrect after the scheduler rearranges instructions, since the instructions don't have the original InstrDist offsets. Additionally, I think it would be more appropriate to use the number of disjointly allocatable registers in the class. For the AMDGPU register tuples, there are a large number of registers in each tuple class, but only a small fraction can actually be allocated at the same time since they all overlap with each other. It seems we do not have a query that corresponds to the number of independently allocatable registers. Relatedly, I'm still debugging some allocation failures where overlapping tuples seem to not be handled correctly. The test changes are mostly noise. There are a handful of x86 tests that look like regressions with an additional spill, and a handful that now avoid a spill. The worst looking regression is likely test/Thumb2/mve-vld4.ll which introduces a few additional spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll shows a massive improvement by completely eliminating a large number of spills inside a loop.
2021-08-22 02:54:51 +08:00
; CHECK-NEXT: sw a0, 4(sp) # 4-byte Folded Spill
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: sw a0, 308(sp)
; CHECK-NEXT: sw a3, 304(sp)
; CHECK-NEXT: sw a2, 300(sp)
; CHECK-NEXT: sw a1, 296(sp)
; CHECK-NEXT: sw s11, 324(sp)
RegAllocGreedy: Account for reserved registers in num regs heuristic This simple heuristic uses the estimated live range length combined with the number of registers in the class to switch which heuristic to use. This was taking the raw number of registers in the class, even though not all of them may be available. AMDGPU heavily relies on dynamically reserved numbers of registers based on user attributes to satisfy occupancy constraints, so the raw number is highly misleading. There are still a few problems here. In the original testcase that made me notice this, the live range size is incorrect after the scheduler rearranges instructions, since the instructions don't have the original InstrDist offsets. Additionally, I think it would be more appropriate to use the number of disjointly allocatable registers in the class. For the AMDGPU register tuples, there are a large number of registers in each tuple class, but only a small fraction can actually be allocated at the same time since they all overlap with each other. It seems we do not have a query that corresponds to the number of independently allocatable registers. Relatedly, I'm still debugging some allocation failures where overlapping tuples seem to not be handled correctly. The test changes are mostly noise. There are a handful of x86 tests that look like regressions with an additional spill, and a handful that now avoid a spill. The worst looking regression is likely test/Thumb2/mve-vld4.ll which introduces a few additional spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll shows a massive improvement by completely eliminating a large number of spills inside a loop.
2021-08-22 02:54:51 +08:00
; CHECK-NEXT: sw s3, 320(sp)
; CHECK-NEXT: sw s5, 316(sp)
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: addi a0, sp, 328
; CHECK-NEXT: addi a1, sp, 312
; CHECK-NEXT: addi a2, sp, 296
RegAllocGreedy: Account for reserved registers in num regs heuristic This simple heuristic uses the estimated live range length combined with the number of registers in the class to switch which heuristic to use. This was taking the raw number of registers in the class, even though not all of them may be available. AMDGPU heavily relies on dynamically reserved numbers of registers based on user attributes to satisfy occupancy constraints, so the raw number is highly misleading. There are still a few problems here. In the original testcase that made me notice this, the live range size is incorrect after the scheduler rearranges instructions, since the instructions don't have the original InstrDist offsets. Additionally, I think it would be more appropriate to use the number of disjointly allocatable registers in the class. For the AMDGPU register tuples, there are a large number of registers in each tuple class, but only a small fraction can actually be allocated at the same time since they all overlap with each other. It seems we do not have a query that corresponds to the number of independently allocatable registers. Relatedly, I'm still debugging some allocation failures where overlapping tuples seem to not be handled correctly. The test changes are mostly noise. There are a handful of x86 tests that look like regressions with an additional spill, and a handful that now avoid a spill. The worst looking regression is likely test/Thumb2/mve-vld4.ll which introduces a few additional spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll shows a massive improvement by completely eliminating a large number of spills inside a loop.
2021-08-22 02:54:51 +08:00
; CHECK-NEXT: sw s4, 312(sp)
[RISCV][NFC] Regenerate RISCV CodeGen tests Regenerated using: ./llvm/utils/update_llc_test_checks.py -u llvm/test/CodeGen/RISCV/*.ll This has added comments to spill-related instructions and added @plt to some symbols. Differential Revision: https://reviews.llvm.org/D92841
2020-12-10 03:41:19 +08:00
; CHECK-NEXT: call __multf3@plt
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: lw a0, 328(sp)
[RISCV][NFC] Regenerate RISCV CodeGen tests Regenerated using: ./llvm/utils/update_llc_test_checks.py -u llvm/test/CodeGen/RISCV/*.ll This has added comments to spill-related instructions and added @plt to some symbols. Differential Revision: https://reviews.llvm.org/D92841
2020-12-10 03:41:19 +08:00
; CHECK-NEXT: sw a0, 44(sp) # 4-byte Folded Spill
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: lw a0, 332(sp)
[RISCV][NFC] Regenerate RISCV CodeGen tests Regenerated using: ./llvm/utils/update_llc_test_checks.py -u llvm/test/CodeGen/RISCV/*.ll This has added comments to spill-related instructions and added @plt to some symbols. Differential Revision: https://reviews.llvm.org/D92841
2020-12-10 03:41:19 +08:00
; CHECK-NEXT: sw a0, 36(sp) # 4-byte Folded Spill
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: lw a0, 336(sp)
[RISCV][NFC] Regenerate RISCV CodeGen tests Regenerated using: ./llvm/utils/update_llc_test_checks.py -u llvm/test/CodeGen/RISCV/*.ll This has added comments to spill-related instructions and added @plt to some symbols. Differential Revision: https://reviews.llvm.org/D92841
2020-12-10 03:41:19 +08:00
; CHECK-NEXT: sw a0, 28(sp) # 4-byte Folded Spill
RegAllocGreedy: Account for reserved registers in num regs heuristic This simple heuristic uses the estimated live range length combined with the number of registers in the class to switch which heuristic to use. This was taking the raw number of registers in the class, even though not all of them may be available. AMDGPU heavily relies on dynamically reserved numbers of registers based on user attributes to satisfy occupancy constraints, so the raw number is highly misleading. There are still a few problems here. In the original testcase that made me notice this, the live range size is incorrect after the scheduler rearranges instructions, since the instructions don't have the original InstrDist offsets. Additionally, I think it would be more appropriate to use the number of disjointly allocatable registers in the class. For the AMDGPU register tuples, there are a large number of registers in each tuple class, but only a small fraction can actually be allocated at the same time since they all overlap with each other. It seems we do not have a query that corresponds to the number of independently allocatable registers. Relatedly, I'm still debugging some allocation failures where overlapping tuples seem to not be handled correctly. The test changes are mostly noise. There are a handful of x86 tests that look like regressions with an additional spill, and a handful that now avoid a spill. The worst looking regression is likely test/Thumb2/mve-vld4.ll which introduces a few additional spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll shows a massive improvement by completely eliminating a large number of spills inside a loop.
2021-08-22 02:54:51 +08:00
; CHECK-NEXT: lw s4, 340(sp)
; CHECK-NEXT: sw s2, 468(sp)
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: sw s8, 464(sp)
; CHECK-NEXT: sw s7, 460(sp)
; CHECK-NEXT: sw s6, 456(sp)
; CHECK-NEXT: sw s1, 452(sp)
RegAllocGreedy: Account for reserved registers in num regs heuristic This simple heuristic uses the estimated live range length combined with the number of registers in the class to switch which heuristic to use. This was taking the raw number of registers in the class, even though not all of them may be available. AMDGPU heavily relies on dynamically reserved numbers of registers based on user attributes to satisfy occupancy constraints, so the raw number is highly misleading. There are still a few problems here. In the original testcase that made me notice this, the live range size is incorrect after the scheduler rearranges instructions, since the instructions don't have the original InstrDist offsets. Additionally, I think it would be more appropriate to use the number of disjointly allocatable registers in the class. For the AMDGPU register tuples, there are a large number of registers in each tuple class, but only a small fraction can actually be allocated at the same time since they all overlap with each other. It seems we do not have a query that corresponds to the number of independently allocatable registers. Relatedly, I'm still debugging some allocation failures where overlapping tuples seem to not be handled correctly. The test changes are mostly noise. There are a handful of x86 tests that look like regressions with an additional spill, and a handful that now avoid a spill. The worst looking regression is likely test/Thumb2/mve-vld4.ll which introduces a few additional spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll shows a massive improvement by completely eliminating a large number of spills inside a loop.
2021-08-22 02:54:51 +08:00
; CHECK-NEXT: sw s0, 448(sp)
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: sw s10, 444(sp)
; CHECK-NEXT: addi a0, sp, 472
; CHECK-NEXT: addi a1, sp, 456
; CHECK-NEXT: addi a2, sp, 440
RegAllocGreedy: Account for reserved registers in num regs heuristic This simple heuristic uses the estimated live range length combined with the number of registers in the class to switch which heuristic to use. This was taking the raw number of registers in the class, even though not all of them may be available. AMDGPU heavily relies on dynamically reserved numbers of registers based on user attributes to satisfy occupancy constraints, so the raw number is highly misleading. There are still a few problems here. In the original testcase that made me notice this, the live range size is incorrect after the scheduler rearranges instructions, since the instructions don't have the original InstrDist offsets. Additionally, I think it would be more appropriate to use the number of disjointly allocatable registers in the class. For the AMDGPU register tuples, there are a large number of registers in each tuple class, but only a small fraction can actually be allocated at the same time since they all overlap with each other. It seems we do not have a query that corresponds to the number of independently allocatable registers. Relatedly, I'm still debugging some allocation failures where overlapping tuples seem to not be handled correctly. The test changes are mostly noise. There are a handful of x86 tests that look like regressions with an additional spill, and a handful that now avoid a spill. The worst looking regression is likely test/Thumb2/mve-vld4.ll which introduces a few additional spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll shows a massive improvement by completely eliminating a large number of spills inside a loop.
2021-08-22 02:54:51 +08:00
; CHECK-NEXT: sw s9, 440(sp)
[RISCV][NFC] Regenerate RISCV CodeGen tests Regenerated using: ./llvm/utils/update_llc_test_checks.py -u llvm/test/CodeGen/RISCV/*.ll This has added comments to spill-related instructions and added @plt to some symbols. Differential Revision: https://reviews.llvm.org/D92841
2020-12-10 03:41:19 +08:00
; CHECK-NEXT: call __addtf3@plt
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: lw a3, 472(sp)
; CHECK-NEXT: lw a0, 476(sp)
; CHECK-NEXT: lw a1, 480(sp)
; CHECK-NEXT: lw a2, 484(sp)
; CHECK-NEXT: sw zero, 420(sp)
; CHECK-NEXT: sw zero, 416(sp)
; CHECK-NEXT: sw zero, 412(sp)
; CHECK-NEXT: sw zero, 408(sp)
; CHECK-NEXT: sw a2, 404(sp)
; CHECK-NEXT: sw a1, 400(sp)
; CHECK-NEXT: sw a0, 396(sp)
; CHECK-NEXT: addi a0, sp, 424
; CHECK-NEXT: addi a1, sp, 408
; CHECK-NEXT: addi a2, sp, 392
; CHECK-NEXT: sw a3, 392(sp)
[RISCV][NFC] Regenerate RISCV CodeGen tests Regenerated using: ./llvm/utils/update_llc_test_checks.py -u llvm/test/CodeGen/RISCV/*.ll This has added comments to spill-related instructions and added @plt to some symbols. Differential Revision: https://reviews.llvm.org/D92841
2020-12-10 03:41:19 +08:00
; CHECK-NEXT: call __subtf3@plt
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: lw a0, 424(sp)
; CHECK-NEXT: lw a1, 436(sp)
; CHECK-NEXT: lw a2, 432(sp)
; CHECK-NEXT: lw a3, 428(sp)
; CHECK-NEXT: lui a4, %hi(X)
; CHECK-NEXT: sw a1, %lo(X+12)(a4)
; CHECK-NEXT: sw a2, %lo(X+8)(a4)
; CHECK-NEXT: sw a3, %lo(X+4)(a4)
; CHECK-NEXT: sw a0, %lo(X)(a4)
RegAllocGreedy: Account for reserved registers in num regs heuristic This simple heuristic uses the estimated live range length combined with the number of registers in the class to switch which heuristic to use. This was taking the raw number of registers in the class, even though not all of them may be available. AMDGPU heavily relies on dynamically reserved numbers of registers based on user attributes to satisfy occupancy constraints, so the raw number is highly misleading. There are still a few problems here. In the original testcase that made me notice this, the live range size is incorrect after the scheduler rearranges instructions, since the instructions don't have the original InstrDist offsets. Additionally, I think it would be more appropriate to use the number of disjointly allocatable registers in the class. For the AMDGPU register tuples, there are a large number of registers in each tuple class, but only a small fraction can actually be allocated at the same time since they all overlap with each other. It seems we do not have a query that corresponds to the number of independently allocatable registers. Relatedly, I'm still debugging some allocation failures where overlapping tuples seem to not be handled correctly. The test changes are mostly noise. There are a handful of x86 tests that look like regressions with an additional spill, and a handful that now avoid a spill. The worst looking regression is likely test/Thumb2/mve-vld4.ll which introduces a few additional spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll shows a massive improvement by completely eliminating a large number of spills inside a loop.
2021-08-22 02:54:51 +08:00
; CHECK-NEXT: lw s8, 4(sp) # 4-byte Folded Reload
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: sw s8, 212(sp)
RegAllocGreedy: Account for reserved registers in num regs heuristic This simple heuristic uses the estimated live range length combined with the number of registers in the class to switch which heuristic to use. This was taking the raw number of registers in the class, even though not all of them may be available. AMDGPU heavily relies on dynamically reserved numbers of registers based on user attributes to satisfy occupancy constraints, so the raw number is highly misleading. There are still a few problems here. In the original testcase that made me notice this, the live range size is incorrect after the scheduler rearranges instructions, since the instructions don't have the original InstrDist offsets. Additionally, I think it would be more appropriate to use the number of disjointly allocatable registers in the class. For the AMDGPU register tuples, there are a large number of registers in each tuple class, but only a small fraction can actually be allocated at the same time since they all overlap with each other. It seems we do not have a query that corresponds to the number of independently allocatable registers. Relatedly, I'm still debugging some allocation failures where overlapping tuples seem to not be handled correctly. The test changes are mostly noise. There are a handful of x86 tests that look like regressions with an additional spill, and a handful that now avoid a spill. The worst looking regression is likely test/Thumb2/mve-vld4.ll which introduces a few additional spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll shows a massive improvement by completely eliminating a large number of spills inside a loop.
2021-08-22 02:54:51 +08:00
; CHECK-NEXT: lw s7, 8(sp) # 4-byte Folded Reload
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: sw s7, 208(sp)
RegAllocGreedy: Account for reserved registers in num regs heuristic This simple heuristic uses the estimated live range length combined with the number of registers in the class to switch which heuristic to use. This was taking the raw number of registers in the class, even though not all of them may be available. AMDGPU heavily relies on dynamically reserved numbers of registers based on user attributes to satisfy occupancy constraints, so the raw number is highly misleading. There are still a few problems here. In the original testcase that made me notice this, the live range size is incorrect after the scheduler rearranges instructions, since the instructions don't have the original InstrDist offsets. Additionally, I think it would be more appropriate to use the number of disjointly allocatable registers in the class. For the AMDGPU register tuples, there are a large number of registers in each tuple class, but only a small fraction can actually be allocated at the same time since they all overlap with each other. It seems we do not have a query that corresponds to the number of independently allocatable registers. Relatedly, I'm still debugging some allocation failures where overlapping tuples seem to not be handled correctly. The test changes are mostly noise. There are a handful of x86 tests that look like regressions with an additional spill, and a handful that now avoid a spill. The worst looking regression is likely test/Thumb2/mve-vld4.ll which introduces a few additional spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll shows a massive improvement by completely eliminating a large number of spills inside a loop.
2021-08-22 02:54:51 +08:00
; CHECK-NEXT: lw s11, 12(sp) # 4-byte Folded Reload
; CHECK-NEXT: sw s11, 204(sp)
[RISCV][NFC] Regenerate RISCV CodeGen tests Regenerated using: ./llvm/utils/update_llc_test_checks.py -u llvm/test/CodeGen/RISCV/*.ll This has added comments to spill-related instructions and added @plt to some symbols. Differential Revision: https://reviews.llvm.org/D92841
2020-12-10 03:41:19 +08:00
; CHECK-NEXT: lw a0, 52(sp) # 4-byte Folded Reload
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: sw a0, 200(sp)
RegAllocGreedy: Account for reserved registers in num regs heuristic This simple heuristic uses the estimated live range length combined with the number of registers in the class to switch which heuristic to use. This was taking the raw number of registers in the class, even though not all of them may be available. AMDGPU heavily relies on dynamically reserved numbers of registers based on user attributes to satisfy occupancy constraints, so the raw number is highly misleading. There are still a few problems here. In the original testcase that made me notice this, the live range size is incorrect after the scheduler rearranges instructions, since the instructions don't have the original InstrDist offsets. Additionally, I think it would be more appropriate to use the number of disjointly allocatable registers in the class. For the AMDGPU register tuples, there are a large number of registers in each tuple class, but only a small fraction can actually be allocated at the same time since they all overlap with each other. It seems we do not have a query that corresponds to the number of independently allocatable registers. Relatedly, I'm still debugging some allocation failures where overlapping tuples seem to not be handled correctly. The test changes are mostly noise. There are a handful of x86 tests that look like regressions with an additional spill, and a handful that now avoid a spill. The worst looking regression is likely test/Thumb2/mve-vld4.ll which introduces a few additional spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll shows a massive improvement by completely eliminating a large number of spills inside a loop.
2021-08-22 02:54:51 +08:00
; CHECK-NEXT: lw a0, 48(sp) # 4-byte Folded Reload
; CHECK-NEXT: sw a0, 228(sp)
; CHECK-NEXT: lw s3, 24(sp) # 4-byte Folded Reload
; CHECK-NEXT: sw s3, 224(sp)
; CHECK-NEXT: lw s2, 32(sp) # 4-byte Folded Reload
; CHECK-NEXT: sw s2, 220(sp)
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: addi a0, sp, 232
; CHECK-NEXT: addi a1, sp, 216
; CHECK-NEXT: addi a2, sp, 200
[RISCV][NFC] Regenerate RISCV CodeGen tests Regenerated using: ./llvm/utils/update_llc_test_checks.py -u llvm/test/CodeGen/RISCV/*.ll This has added comments to spill-related instructions and added @plt to some symbols. Differential Revision: https://reviews.llvm.org/D92841
2020-12-10 03:41:19 +08:00
; CHECK-NEXT: lw s1, 40(sp) # 4-byte Folded Reload
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: sw s1, 216(sp)
[RISCV][NFC] Regenerate RISCV CodeGen tests Regenerated using: ./llvm/utils/update_llc_test_checks.py -u llvm/test/CodeGen/RISCV/*.ll This has added comments to spill-related instructions and added @plt to some symbols. Differential Revision: https://reviews.llvm.org/D92841
2020-12-10 03:41:19 +08:00
; CHECK-NEXT: call __multf3@plt
RegAllocGreedy: Account for reserved registers in num regs heuristic This simple heuristic uses the estimated live range length combined with the number of registers in the class to switch which heuristic to use. This was taking the raw number of registers in the class, even though not all of them may be available. AMDGPU heavily relies on dynamically reserved numbers of registers based on user attributes to satisfy occupancy constraints, so the raw number is highly misleading. There are still a few problems here. In the original testcase that made me notice this, the live range size is incorrect after the scheduler rearranges instructions, since the instructions don't have the original InstrDist offsets. Additionally, I think it would be more appropriate to use the number of disjointly allocatable registers in the class. For the AMDGPU register tuples, there are a large number of registers in each tuple class, but only a small fraction can actually be allocated at the same time since they all overlap with each other. It seems we do not have a query that corresponds to the number of independently allocatable registers. Relatedly, I'm still debugging some allocation failures where overlapping tuples seem to not be handled correctly. The test changes are mostly noise. There are a handful of x86 tests that look like regressions with an additional spill, and a handful that now avoid a spill. The worst looking regression is likely test/Thumb2/mve-vld4.ll which introduces a few additional spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll shows a massive improvement by completely eliminating a large number of spills inside a loop.
2021-08-22 02:54:51 +08:00
; CHECK-NEXT: lw s5, 232(sp)
; CHECK-NEXT: lw a0, 236(sp)
; CHECK-NEXT: sw a0, 0(sp) # 4-byte Folded Spill
; CHECK-NEXT: lw s6, 240(sp)
; CHECK-NEXT: lw s0, 244(sp)
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: sw zero, 356(sp)
; CHECK-NEXT: sw zero, 352(sp)
; CHECK-NEXT: sw zero, 348(sp)
; CHECK-NEXT: sw zero, 344(sp)
RegAllocGreedy: Account for reserved registers in num regs heuristic This simple heuristic uses the estimated live range length combined with the number of registers in the class to switch which heuristic to use. This was taking the raw number of registers in the class, even though not all of them may be available. AMDGPU heavily relies on dynamically reserved numbers of registers based on user attributes to satisfy occupancy constraints, so the raw number is highly misleading. There are still a few problems here. In the original testcase that made me notice this, the live range size is incorrect after the scheduler rearranges instructions, since the instructions don't have the original InstrDist offsets. Additionally, I think it would be more appropriate to use the number of disjointly allocatable registers in the class. For the AMDGPU register tuples, there are a large number of registers in each tuple class, but only a small fraction can actually be allocated at the same time since they all overlap with each other. It seems we do not have a query that corresponds to the number of independently allocatable registers. Relatedly, I'm still debugging some allocation failures where overlapping tuples seem to not be handled correctly. The test changes are mostly noise. There are a handful of x86 tests that look like regressions with an additional spill, and a handful that now avoid a spill. The worst looking regression is likely test/Thumb2/mve-vld4.ll which introduces a few additional spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll shows a massive improvement by completely eliminating a large number of spills inside a loop.
2021-08-22 02:54:51 +08:00
; CHECK-NEXT: lw a0, 16(sp) # 4-byte Folded Reload
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: sw a0, 372(sp)
RegAllocGreedy: Account for reserved registers in num regs heuristic This simple heuristic uses the estimated live range length combined with the number of registers in the class to switch which heuristic to use. This was taking the raw number of registers in the class, even though not all of them may be available. AMDGPU heavily relies on dynamically reserved numbers of registers based on user attributes to satisfy occupancy constraints, so the raw number is highly misleading. There are still a few problems here. In the original testcase that made me notice this, the live range size is incorrect after the scheduler rearranges instructions, since the instructions don't have the original InstrDist offsets. Additionally, I think it would be more appropriate to use the number of disjointly allocatable registers in the class. For the AMDGPU register tuples, there are a large number of registers in each tuple class, but only a small fraction can actually be allocated at the same time since they all overlap with each other. It seems we do not have a query that corresponds to the number of independently allocatable registers. Relatedly, I'm still debugging some allocation failures where overlapping tuples seem to not be handled correctly. The test changes are mostly noise. There are a handful of x86 tests that look like regressions with an additional spill, and a handful that now avoid a spill. The worst looking regression is likely test/Thumb2/mve-vld4.ll which introduces a few additional spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll shows a massive improvement by completely eliminating a large number of spills inside a loop.
2021-08-22 02:54:51 +08:00
; CHECK-NEXT: lw a0, 20(sp) # 4-byte Folded Reload
; CHECK-NEXT: sw a0, 368(sp)
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: sw s10, 364(sp)
; CHECK-NEXT: addi a0, sp, 376
; CHECK-NEXT: addi a1, sp, 360
; CHECK-NEXT: addi a2, sp, 344
RegAllocGreedy: Account for reserved registers in num regs heuristic This simple heuristic uses the estimated live range length combined with the number of registers in the class to switch which heuristic to use. This was taking the raw number of registers in the class, even though not all of them may be available. AMDGPU heavily relies on dynamically reserved numbers of registers based on user attributes to satisfy occupancy constraints, so the raw number is highly misleading. There are still a few problems here. In the original testcase that made me notice this, the live range size is incorrect after the scheduler rearranges instructions, since the instructions don't have the original InstrDist offsets. Additionally, I think it would be more appropriate to use the number of disjointly allocatable registers in the class. For the AMDGPU register tuples, there are a large number of registers in each tuple class, but only a small fraction can actually be allocated at the same time since they all overlap with each other. It seems we do not have a query that corresponds to the number of independently allocatable registers. Relatedly, I'm still debugging some allocation failures where overlapping tuples seem to not be handled correctly. The test changes are mostly noise. There are a handful of x86 tests that look like regressions with an additional spill, and a handful that now avoid a spill. The worst looking regression is likely test/Thumb2/mve-vld4.ll which introduces a few additional spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll shows a massive improvement by completely eliminating a large number of spills inside a loop.
2021-08-22 02:54:51 +08:00
; CHECK-NEXT: sw s9, 360(sp)
[RISCV][NFC] Regenerate RISCV CodeGen tests Regenerated using: ./llvm/utils/update_llc_test_checks.py -u llvm/test/CodeGen/RISCV/*.ll This has added comments to spill-related instructions and added @plt to some symbols. Differential Revision: https://reviews.llvm.org/D92841
2020-12-10 03:41:19 +08:00
; CHECK-NEXT: call __multf3@plt
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: lw a0, 376(sp)
; CHECK-NEXT: lw a1, 388(sp)
; CHECK-NEXT: lw a2, 384(sp)
; CHECK-NEXT: lw a3, 380(sp)
; CHECK-NEXT: lui a4, %hi(S)
; CHECK-NEXT: sw a1, %lo(S+12)(a4)
; CHECK-NEXT: sw a2, %lo(S+8)(a4)
; CHECK-NEXT: sw a3, %lo(S+4)(a4)
; CHECK-NEXT: sw a0, %lo(S)(a4)
RegAllocGreedy: Account for reserved registers in num regs heuristic This simple heuristic uses the estimated live range length combined with the number of registers in the class to switch which heuristic to use. This was taking the raw number of registers in the class, even though not all of them may be available. AMDGPU heavily relies on dynamically reserved numbers of registers based on user attributes to satisfy occupancy constraints, so the raw number is highly misleading. There are still a few problems here. In the original testcase that made me notice this, the live range size is incorrect after the scheduler rearranges instructions, since the instructions don't have the original InstrDist offsets. Additionally, I think it would be more appropriate to use the number of disjointly allocatable registers in the class. For the AMDGPU register tuples, there are a large number of registers in each tuple class, but only a small fraction can actually be allocated at the same time since they all overlap with each other. It seems we do not have a query that corresponds to the number of independently allocatable registers. Relatedly, I'm still debugging some allocation failures where overlapping tuples seem to not be handled correctly. The test changes are mostly noise. There are a handful of x86 tests that look like regressions with an additional spill, and a handful that now avoid a spill. The worst looking regression is likely test/Thumb2/mve-vld4.ll which introduces a few additional spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll shows a massive improvement by completely eliminating a large number of spills inside a loop.
2021-08-22 02:54:51 +08:00
; CHECK-NEXT: lw a0, 48(sp) # 4-byte Folded Reload
; CHECK-NEXT: sw a0, 260(sp)
; CHECK-NEXT: sw s3, 256(sp)
; CHECK-NEXT: sw s2, 252(sp)
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: sw s1, 248(sp)
RegAllocGreedy: Account for reserved registers in num regs heuristic This simple heuristic uses the estimated live range length combined with the number of registers in the class to switch which heuristic to use. This was taking the raw number of registers in the class, even though not all of them may be available. AMDGPU heavily relies on dynamically reserved numbers of registers based on user attributes to satisfy occupancy constraints, so the raw number is highly misleading. There are still a few problems here. In the original testcase that made me notice this, the live range size is incorrect after the scheduler rearranges instructions, since the instructions don't have the original InstrDist offsets. Additionally, I think it would be more appropriate to use the number of disjointly allocatable registers in the class. For the AMDGPU register tuples, there are a large number of registers in each tuple class, but only a small fraction can actually be allocated at the same time since they all overlap with each other. It seems we do not have a query that corresponds to the number of independently allocatable registers. Relatedly, I'm still debugging some allocation failures where overlapping tuples seem to not be handled correctly. The test changes are mostly noise. There are a handful of x86 tests that look like regressions with an additional spill, and a handful that now avoid a spill. The worst looking regression is likely test/Thumb2/mve-vld4.ll which introduces a few additional spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll shows a massive improvement by completely eliminating a large number of spills inside a loop.
2021-08-22 02:54:51 +08:00
; CHECK-NEXT: sw s4, 276(sp)
[RISCV][NFC] Regenerate RISCV CodeGen tests Regenerated using: ./llvm/utils/update_llc_test_checks.py -u llvm/test/CodeGen/RISCV/*.ll This has added comments to spill-related instructions and added @plt to some symbols. Differential Revision: https://reviews.llvm.org/D92841
2020-12-10 03:41:19 +08:00
; CHECK-NEXT: lw a0, 28(sp) # 4-byte Folded Reload
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: sw a0, 272(sp)
[RISCV][NFC] Regenerate RISCV CodeGen tests Regenerated using: ./llvm/utils/update_llc_test_checks.py -u llvm/test/CodeGen/RISCV/*.ll This has added comments to spill-related instructions and added @plt to some symbols. Differential Revision: https://reviews.llvm.org/D92841
2020-12-10 03:41:19 +08:00
; CHECK-NEXT: lw a0, 36(sp) # 4-byte Folded Reload
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: sw a0, 268(sp)
; CHECK-NEXT: addi a0, sp, 280
; CHECK-NEXT: addi a1, sp, 264
; CHECK-NEXT: addi a2, sp, 248
[RISCV][NFC] Regenerate RISCV CodeGen tests Regenerated using: ./llvm/utils/update_llc_test_checks.py -u llvm/test/CodeGen/RISCV/*.ll This has added comments to spill-related instructions and added @plt to some symbols. Differential Revision: https://reviews.llvm.org/D92841
2020-12-10 03:41:19 +08:00
; CHECK-NEXT: lw a3, 44(sp) # 4-byte Folded Reload
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: sw a3, 264(sp)
[RISCV][NFC] Regenerate RISCV CodeGen tests Regenerated using: ./llvm/utils/update_llc_test_checks.py -u llvm/test/CodeGen/RISCV/*.ll This has added comments to spill-related instructions and added @plt to some symbols. Differential Revision: https://reviews.llvm.org/D92841
2020-12-10 03:41:19 +08:00
; CHECK-NEXT: call __subtf3@plt
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: lw a0, 280(sp)
; CHECK-NEXT: lw a1, 292(sp)
; CHECK-NEXT: lw a2, 288(sp)
; CHECK-NEXT: lw a3, 284(sp)
; CHECK-NEXT: lui a4, %hi(T)
; CHECK-NEXT: sw a1, %lo(T+12)(a4)
; CHECK-NEXT: sw a2, %lo(T+8)(a4)
; CHECK-NEXT: sw a3, %lo(T+4)(a4)
; CHECK-NEXT: sw a0, %lo(T)(a4)
; CHECK-NEXT: sw zero, 164(sp)
; CHECK-NEXT: sw zero, 160(sp)
; CHECK-NEXT: sw zero, 156(sp)
; CHECK-NEXT: sw zero, 152(sp)
RegAllocGreedy: Account for reserved registers in num regs heuristic This simple heuristic uses the estimated live range length combined with the number of registers in the class to switch which heuristic to use. This was taking the raw number of registers in the class, even though not all of them may be available. AMDGPU heavily relies on dynamically reserved numbers of registers based on user attributes to satisfy occupancy constraints, so the raw number is highly misleading. There are still a few problems here. In the original testcase that made me notice this, the live range size is incorrect after the scheduler rearranges instructions, since the instructions don't have the original InstrDist offsets. Additionally, I think it would be more appropriate to use the number of disjointly allocatable registers in the class. For the AMDGPU register tuples, there are a large number of registers in each tuple class, but only a small fraction can actually be allocated at the same time since they all overlap with each other. It seems we do not have a query that corresponds to the number of independently allocatable registers. Relatedly, I'm still debugging some allocation failures where overlapping tuples seem to not be handled correctly. The test changes are mostly noise. There are a handful of x86 tests that look like regressions with an additional spill, and a handful that now avoid a spill. The worst looking regression is likely test/Thumb2/mve-vld4.ll which introduces a few additional spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll shows a massive improvement by completely eliminating a large number of spills inside a loop.
2021-08-22 02:54:51 +08:00
; CHECK-NEXT: sw s0, 180(sp)
; CHECK-NEXT: sw s6, 176(sp)
; CHECK-NEXT: lw a0, 0(sp) # 4-byte Folded Reload
; CHECK-NEXT: sw a0, 172(sp)
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: addi a0, sp, 184
; CHECK-NEXT: addi a1, sp, 168
; CHECK-NEXT: addi a2, sp, 152
RegAllocGreedy: Account for reserved registers in num regs heuristic This simple heuristic uses the estimated live range length combined with the number of registers in the class to switch which heuristic to use. This was taking the raw number of registers in the class, even though not all of them may be available. AMDGPU heavily relies on dynamically reserved numbers of registers based on user attributes to satisfy occupancy constraints, so the raw number is highly misleading. There are still a few problems here. In the original testcase that made me notice this, the live range size is incorrect after the scheduler rearranges instructions, since the instructions don't have the original InstrDist offsets. Additionally, I think it would be more appropriate to use the number of disjointly allocatable registers in the class. For the AMDGPU register tuples, there are a large number of registers in each tuple class, but only a small fraction can actually be allocated at the same time since they all overlap with each other. It seems we do not have a query that corresponds to the number of independently allocatable registers. Relatedly, I'm still debugging some allocation failures where overlapping tuples seem to not be handled correctly. The test changes are mostly noise. There are a handful of x86 tests that look like regressions with an additional spill, and a handful that now avoid a spill. The worst looking regression is likely test/Thumb2/mve-vld4.ll which introduces a few additional spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll shows a massive improvement by completely eliminating a large number of spills inside a loop.
2021-08-22 02:54:51 +08:00
; CHECK-NEXT: sw s5, 168(sp)
[RISCV][NFC] Regenerate RISCV CodeGen tests Regenerated using: ./llvm/utils/update_llc_test_checks.py -u llvm/test/CodeGen/RISCV/*.ll This has added comments to spill-related instructions and added @plt to some symbols. Differential Revision: https://reviews.llvm.org/D92841
2020-12-10 03:41:19 +08:00
; CHECK-NEXT: call __addtf3@plt
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: lw a0, 184(sp)
; CHECK-NEXT: lw a1, 196(sp)
; CHECK-NEXT: lw a2, 192(sp)
; CHECK-NEXT: lw a3, 188(sp)
; CHECK-NEXT: lui a4, %hi(Y)
; CHECK-NEXT: sw a1, %lo(Y+12)(a4)
; CHECK-NEXT: sw a2, %lo(Y+8)(a4)
; CHECK-NEXT: sw a3, %lo(Y+4)(a4)
; CHECK-NEXT: sw a0, %lo(Y)(a4)
; CHECK-NEXT: sw zero, 116(sp)
; CHECK-NEXT: sw zero, 112(sp)
; CHECK-NEXT: sw zero, 108(sp)
; CHECK-NEXT: sw zero, 104(sp)
; CHECK-NEXT: sw s8, 132(sp)
; CHECK-NEXT: sw s7, 128(sp)
RegAllocGreedy: Account for reserved registers in num regs heuristic This simple heuristic uses the estimated live range length combined with the number of registers in the class to switch which heuristic to use. This was taking the raw number of registers in the class, even though not all of them may be available. AMDGPU heavily relies on dynamically reserved numbers of registers based on user attributes to satisfy occupancy constraints, so the raw number is highly misleading. There are still a few problems here. In the original testcase that made me notice this, the live range size is incorrect after the scheduler rearranges instructions, since the instructions don't have the original InstrDist offsets. Additionally, I think it would be more appropriate to use the number of disjointly allocatable registers in the class. For the AMDGPU register tuples, there are a large number of registers in each tuple class, but only a small fraction can actually be allocated at the same time since they all overlap with each other. It seems we do not have a query that corresponds to the number of independently allocatable registers. Relatedly, I'm still debugging some allocation failures where overlapping tuples seem to not be handled correctly. The test changes are mostly noise. There are a handful of x86 tests that look like regressions with an additional spill, and a handful that now avoid a spill. The worst looking regression is likely test/Thumb2/mve-vld4.ll which introduces a few additional spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll shows a massive improvement by completely eliminating a large number of spills inside a loop.
2021-08-22 02:54:51 +08:00
; CHECK-NEXT: sw s11, 124(sp)
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: addi a0, sp, 136
; CHECK-NEXT: addi a1, sp, 120
; CHECK-NEXT: addi a2, sp, 104
RegAllocGreedy: Account for reserved registers in num regs heuristic This simple heuristic uses the estimated live range length combined with the number of registers in the class to switch which heuristic to use. This was taking the raw number of registers in the class, even though not all of them may be available. AMDGPU heavily relies on dynamically reserved numbers of registers based on user attributes to satisfy occupancy constraints, so the raw number is highly misleading. There are still a few problems here. In the original testcase that made me notice this, the live range size is incorrect after the scheduler rearranges instructions, since the instructions don't have the original InstrDist offsets. Additionally, I think it would be more appropriate to use the number of disjointly allocatable registers in the class. For the AMDGPU register tuples, there are a large number of registers in each tuple class, but only a small fraction can actually be allocated at the same time since they all overlap with each other. It seems we do not have a query that corresponds to the number of independently allocatable registers. Relatedly, I'm still debugging some allocation failures where overlapping tuples seem to not be handled correctly. The test changes are mostly noise. There are a handful of x86 tests that look like regressions with an additional spill, and a handful that now avoid a spill. The worst looking regression is likely test/Thumb2/mve-vld4.ll which introduces a few additional spills. test/CodeGen/AMDGPU/soft-clause-exceeds-register-budget.ll shows a massive improvement by completely eliminating a large number of spills inside a loop.
2021-08-22 02:54:51 +08:00
; CHECK-NEXT: lw a3, 52(sp) # 4-byte Folded Reload
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: sw a3, 120(sp)
[RISCV][NFC] Regenerate RISCV CodeGen tests Regenerated using: ./llvm/utils/update_llc_test_checks.py -u llvm/test/CodeGen/RISCV/*.ll This has added comments to spill-related instructions and added @plt to some symbols. Differential Revision: https://reviews.llvm.org/D92841
2020-12-10 03:41:19 +08:00
; CHECK-NEXT: call __multf3@plt
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: lw a3, 136(sp)
; CHECK-NEXT: lw a0, 140(sp)
; CHECK-NEXT: lw a1, 144(sp)
; CHECK-NEXT: lw a2, 148(sp)
; CHECK-NEXT: lui a4, 786400
; CHECK-NEXT: sw a4, 68(sp)
; CHECK-NEXT: sw zero, 64(sp)
; CHECK-NEXT: sw zero, 60(sp)
; CHECK-NEXT: sw zero, 56(sp)
; CHECK-NEXT: sw a2, 84(sp)
; CHECK-NEXT: sw a1, 80(sp)
; CHECK-NEXT: sw a0, 76(sp)
; CHECK-NEXT: addi a0, sp, 88
; CHECK-NEXT: addi a1, sp, 72
; CHECK-NEXT: addi a2, sp, 56
; CHECK-NEXT: sw a3, 72(sp)
[RISCV][NFC] Regenerate RISCV CodeGen tests Regenerated using: ./llvm/utils/update_llc_test_checks.py -u llvm/test/CodeGen/RISCV/*.ll This has added comments to spill-related instructions and added @plt to some symbols. Differential Revision: https://reviews.llvm.org/D92841
2020-12-10 03:41:19 +08:00
; CHECK-NEXT: call __addtf3@plt
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: lw a0, 96(sp)
; CHECK-NEXT: lw a1, 100(sp)
; CHECK-NEXT: lw a2, 88(sp)
; CHECK-NEXT: lw a3, 92(sp)
; CHECK-NEXT: lui a4, %hi(Y1)
; CHECK-NEXT: sw a0, %lo(Y1+8)(a4)
; CHECK-NEXT: sw a1, %lo(Y1+12)(a4)
; CHECK-NEXT: sw a2, %lo(Y1)(a4)
; CHECK-NEXT: sw a3, %lo(Y1+4)(a4)
[RISCV][NFC] Regenerate RISCV CodeGen tests Regenerated using: ./llvm/utils/update_llc_test_checks.py -u llvm/test/CodeGen/RISCV/*.ll This has added comments to spill-related instructions and added @plt to some symbols. Differential Revision: https://reviews.llvm.org/D92841
2020-12-10 03:41:19 +08:00
; CHECK-NEXT: lw s11, 636(sp) # 4-byte Folded Reload
; CHECK-NEXT: lw s10, 640(sp) # 4-byte Folded Reload
; CHECK-NEXT: lw s9, 644(sp) # 4-byte Folded Reload
; CHECK-NEXT: lw s8, 648(sp) # 4-byte Folded Reload
; CHECK-NEXT: lw s7, 652(sp) # 4-byte Folded Reload
; CHECK-NEXT: lw s6, 656(sp) # 4-byte Folded Reload
; CHECK-NEXT: lw s5, 660(sp) # 4-byte Folded Reload
; CHECK-NEXT: lw s4, 664(sp) # 4-byte Folded Reload
; CHECK-NEXT: lw s3, 668(sp) # 4-byte Folded Reload
; CHECK-NEXT: lw s2, 672(sp) # 4-byte Folded Reload
; CHECK-NEXT: lw s1, 676(sp) # 4-byte Folded Reload
; CHECK-NEXT: lw s0, 680(sp) # 4-byte Folded Reload
; CHECK-NEXT: lw ra, 684(sp) # 4-byte Folded Reload
[NFC][RISCV] Test for D81805 New test to show the changes after D81805 is committed. Differential Revision: https://reviews.llvm.org/D83750
2020-07-14 15:18:07 +08:00
; CHECK-NEXT: addi sp, sp, 688
; CHECK-NEXT: ret
%1 = load fp128, fp128* @U, align 16
%2 = fsub fp128 0xL00000000000000000000000000000000, %1
%3 = fsub fp128 %2, %1
%4 = fadd fp128 %1, 0xL00000000000000000000000000000000
%5 = load fp128, fp128* @Y1, align 16
%6 = fmul fp128 %2, %5
%7 = fadd fp128 %1, %4
%8 = fsub fp128 0xL00000000000000000000000000000000, %7
store fp128 %8, fp128* @X, align 16
%9 = fmul fp128 %3, %5
%10 = fmul fp128 0xL00000000000000000000000000000000, %4
store fp128 %10, fp128* @S, align 16
%11 = fsub fp128 %6, %3
store fp128 %11, fp128* @T, align 16
%12 = fadd fp128 0xL00000000000000000000000000000000, %9
store fp128 %12, fp128* @Y, align 16
%13 = fmul fp128 0xL00000000000000000000000000000000, %5
%14 = fadd fp128 %13, 0xL0000000000000000BFFE000000000000
store fp128 %14, fp128* @Y1, align 16
ret void
}