RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-23 19:23:23 +01:00
Code Issues Projects Releases Wiki Activity
1bdd822573
llvm-mirror/test/CodeGen/X86/usub_inc_iv.ll

408 lines
16 KiB
LLVM
Raw Normal View History

[Test] Add tests demonstrating missing case of usub with overflow usage The test shows how "usub with overflow" opt gets or does not get applied to increment of IV depending on its code placement, while two cases are semantically equivalent.
2021-02-05 12:27:42 +01:00
; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
; RUN: opt -mtriple=x86_64-linux -codegenprepare -S < %s | FileCheck %s
define i32 @test_01(i32* %p, i64 %len, i32 %x) {
; CHECK-LABEL: @test_01(
; CHECK-NEXT: entry:
; CHECK-NEXT: br label [[LOOP:%.*]]
; CHECK: loop:
; CHECK-NEXT: [[IV:%.*]] = phi i64 [ [[MATH:%.*]], [[BACKEDGE:%.*]] ], [ [[LEN:%.*]], [[ENTRY:%.*]] ]
; CHECK-NEXT: [[TMP0:%.*]] = call { i64, i1 } @llvm.usub.with.overflow.i64(i64 [[IV]], i64 1)
; CHECK-NEXT: [[MATH]] = extractvalue { i64, i1 } [[TMP0]], 0
; CHECK-NEXT: [[OV:%.*]] = extractvalue { i64, i1 } [[TMP0]], 1
; CHECK-NEXT: br i1 [[OV]], label [[EXIT:%.*]], label [[BACKEDGE]]
; CHECK: backedge:
[X86][CodeGenPrepare] Try to reuse IV's incremented value instead of adding the offset, part 1 While optimizing the memory instruction, we sometimes need to add offset to the value of `IV`. We could avoid doing so if the `IV.next` is already defined at the point of interest. In this case, we may get two possible advantages from this: - If the `IV` step happens to match with the offset, we don't need to add the offset at all; - We reduce overlap of live ranges of `IV` and `IV.next`. They may stop overlapping and it will lead to better register allocation. Even if the overlap will preserve, we are not introducing a new overlap, so it should be a neutral transform (Disabled this patch, will come with follow-up). Currently I've only added support for IVs that get decremented using `usub` intrinsic. We could also support `AddInstr`, however there is some weird interaction with some other transform that may lead to infinite compilation in this case (seems like same transform is done and undone over and over). I need to investigate why it happens, but generally we could do that too. The first part only handles case where this reuse fully elimiates the offset. Differential Revision: https://reviews.llvm.org/D96399 Reviewed By: reames
2021-03-04 06:01:39 +01:00
; CHECK-NEXT: [[SUNKADDR:%.*]] = mul i64 [[MATH]], 4
[Test] Add tests demonstrating missing case of usub with overflow usage The test shows how "usub with overflow" opt gets or does not get applied to increment of IV depending on its code placement, while two cases are semantically equivalent.
2021-02-05 12:27:42 +01:00
; CHECK-NEXT: [[TMP1:%.*]] = bitcast i32* [[P:%.*]] to i8*
; CHECK-NEXT: [[SUNKADDR1:%.*]] = getelementptr i8, i8* [[TMP1]], i64 [[SUNKADDR]]
[X86][CodeGenPrepare] Try to reuse IV's incremented value instead of adding the offset, part 1 While optimizing the memory instruction, we sometimes need to add offset to the value of `IV`. We could avoid doing so if the `IV.next` is already defined at the point of interest. In this case, we may get two possible advantages from this: - If the `IV` step happens to match with the offset, we don't need to add the offset at all; - We reduce overlap of live ranges of `IV` and `IV.next`. They may stop overlapping and it will lead to better register allocation. Even if the overlap will preserve, we are not introducing a new overlap, so it should be a neutral transform (Disabled this patch, will come with follow-up). Currently I've only added support for IVs that get decremented using `usub` intrinsic. We could also support `AddInstr`, however there is some weird interaction with some other transform that may lead to infinite compilation in this case (seems like same transform is done and undone over and over). I need to investigate why it happens, but generally we could do that too. The first part only handles case where this reuse fully elimiates the offset. Differential Revision: https://reviews.llvm.org/D96399 Reviewed By: reames
2021-03-04 06:01:39 +01:00
; CHECK-NEXT: [[TMP2:%.*]] = bitcast i8* [[SUNKADDR1]] to i32*
[Test] Add tests demonstrating missing case of usub with overflow usage The test shows how "usub with overflow" opt gets or does not get applied to increment of IV depending on its code placement, while two cases are semantically equivalent.
2021-02-05 12:27:42 +01:00
; CHECK-NEXT: [[LOADED:%.*]] = load atomic i32, i32* [[TMP2]] unordered, align 4
; CHECK-NEXT: [[COND_2:%.*]] = icmp eq i32 [[LOADED]], [[X:%.*]]
; CHECK-NEXT: br i1 [[COND_2]], label [[FAILURE:%.*]], label [[LOOP]]
; CHECK: exit:
; CHECK-NEXT: ret i32 -1
; CHECK: failure:
; CHECK-NEXT: unreachable
;
entry:
%scevgep = getelementptr i32, i32* %p, i64 -1
br label %loop
loop: ; preds = %backedge, %entry
%iv = phi i64 [ %iv.next, %backedge ], [ %len, %entry ]
%iv.next = add i64 %iv, -1
%cond_1 = icmp eq i64 %iv, 0
br i1 %cond_1, label %exit, label %backedge
backedge: ; preds = %loop
%scevgep1 = getelementptr i32, i32* %scevgep, i64 %iv
%loaded = load atomic i32, i32* %scevgep1 unordered, align 4
%cond_2 = icmp eq i32 %loaded, %x
br i1 %cond_2, label %failure, label %loop
exit: ; preds = %loop
ret i32 -1
failure: ; preds = %backedge
unreachable
}
[Test] Two more tests on usub They are analogous to the existing tests, but use different starting offset which can be important for some transforms.
2021-02-10 06:28:08 +01:00
; Similar to test_01, but with different offset.
define i32 @test_01a(i32* %p, i64 %len, i32 %x) {
; CHECK-LABEL: @test_01a(
; CHECK-NEXT: entry:
; CHECK-NEXT: br label [[LOOP:%.*]]
; CHECK: loop:
; CHECK-NEXT: [[IV:%.*]] = phi i64 [ [[MATH:%.*]], [[BACKEDGE:%.*]] ], [ [[LEN:%.*]], [[ENTRY:%.*]] ]
; CHECK-NEXT: [[TMP0:%.*]] = call { i64, i1 } @llvm.usub.with.overflow.i64(i64 [[IV]], i64 1)
; CHECK-NEXT: [[MATH]] = extractvalue { i64, i1 } [[TMP0]], 0
; CHECK-NEXT: [[OV:%.*]] = extractvalue { i64, i1 } [[TMP0]], 1
; CHECK-NEXT: br i1 [[OV]], label [[EXIT:%.*]], label [[BACKEDGE]]
; CHECK: backedge:
[X86][CodeGenPrepare] Try to reuse IV's incremented value instead of adding the offset, part 2 This patch enables the case where we do not completely eliminate offset. Supposedly in this case we reduce live range overlap that never harms, but since there are doubts this is true, this goes as a separate change. Differential Revision: https://reviews.llvm.org/D96399 Reviewed By: reames
2021-03-04 09:41:22 +01:00
; CHECK-NEXT: [[SUNKADDR:%.*]] = mul i64 [[MATH]], 4
[Test] Two more tests on usub They are analogous to the existing tests, but use different starting offset which can be important for some transforms.
2021-02-10 06:28:08 +01:00
; CHECK-NEXT: [[TMP1:%.*]] = bitcast i32* [[P:%.*]] to i8*
; CHECK-NEXT: [[SUNKADDR1:%.*]] = getelementptr i8, i8* [[TMP1]], i64 [[SUNKADDR]]
[X86][CodeGenPrepare] Try to reuse IV's incremented value instead of adding the offset, part 2 This patch enables the case where we do not completely eliminate offset. Supposedly in this case we reduce live range overlap that never harms, but since there are doubts this is true, this goes as a separate change. Differential Revision: https://reviews.llvm.org/D96399 Reviewed By: reames
2021-03-04 09:41:22 +01:00
; CHECK-NEXT: [[SUNKADDR2:%.*]] = getelementptr i8, i8* [[SUNKADDR1]], i64 -24
[Test] Two more tests on usub They are analogous to the existing tests, but use different starting offset which can be important for some transforms.
2021-02-10 06:28:08 +01:00
; CHECK-NEXT: [[TMP2:%.*]] = bitcast i8* [[SUNKADDR2]] to i32*
; CHECK-NEXT: [[LOADED:%.*]] = load atomic i32, i32* [[TMP2]] unordered, align 4
; CHECK-NEXT: [[COND_2:%.*]] = icmp eq i32 [[LOADED]], [[X:%.*]]
; CHECK-NEXT: br i1 [[COND_2]], label [[FAILURE:%.*]], label [[LOOP]]
; CHECK: exit:
; CHECK-NEXT: ret i32 -1
; CHECK: failure:
; CHECK-NEXT: unreachable
;
entry:
%scevgep = getelementptr i32, i32* %p, i64 -7
br label %loop
loop: ; preds = %backedge, %entry
%iv = phi i64 [ %iv.next, %backedge ], [ %len, %entry ]
%iv.next = add i64 %iv, -1
%cond_1 = icmp eq i64 %iv, 0
br i1 %cond_1, label %exit, label %backedge
backedge: ; preds = %loop
%scevgep1 = getelementptr i32, i32* %scevgep, i64 %iv
%loaded = load atomic i32, i32* %scevgep1 unordered, align 4
%cond_2 = icmp eq i32 %loaded, %x
br i1 %cond_2, label %failure, label %loop
exit: ; preds = %loop
ret i32 -1
failure: ; preds = %backedge
unreachable
}
[Test] Add tests demonstrating missing case of usub with overflow usage The test shows how "usub with overflow" opt gets or does not get applied to increment of IV depending on its code placement, while two cases are semantically equivalent.
2021-02-05 12:27:42 +01:00
; TODO: We can use trick with usub here.
define i32 @test_02(i32* %p, i64 %len, i32 %x) {
; CHECK-LABEL: @test_02(
; CHECK-NEXT: entry:
; CHECK-NEXT: br label [[LOOP:%.*]]
; CHECK: loop:
Return "[Codegenprepare][X86] Use usub with overflow opt for IV increment" The patch did not account for one corner case where cmp does not dominate the loop latch. This patch adds this check, hopefully it's cheap because the CFG does not change during the transform, so DT queries should be executed quickly. If you see compile time slowness from this, please revert. Differential Revision: https://reviews.llvm.org/D96119
2021-02-11 13:25:30 +01:00
; CHECK-NEXT: [[IV:%.*]] = phi i64 [ [[MATH:%.*]], [[BACKEDGE:%.*]] ], [ [[LEN:%.*]], [[ENTRY:%.*]] ]
; CHECK-NEXT: [[TMP0:%.*]] = call { i64, i1 } @llvm.usub.with.overflow.i64(i64 [[IV]], i64 1)
; CHECK-NEXT: [[MATH]] = extractvalue { i64, i1 } [[TMP0]], 0
; CHECK-NEXT: [[OV:%.*]] = extractvalue { i64, i1 } [[TMP0]], 1
; CHECK-NEXT: br i1 [[OV]], label [[EXIT:%.*]], label [[BACKEDGE]]
[Test] Add tests demonstrating missing case of usub with overflow usage The test shows how "usub with overflow" opt gets or does not get applied to increment of IV depending on its code placement, while two cases are semantically equivalent.
2021-02-05 12:27:42 +01:00
; CHECK: backedge:
[X86][CodeGenPrepare] Try to reuse IV's incremented value instead of adding the offset, part 1 While optimizing the memory instruction, we sometimes need to add offset to the value of `IV`. We could avoid doing so if the `IV.next` is already defined at the point of interest. In this case, we may get two possible advantages from this: - If the `IV` step happens to match with the offset, we don't need to add the offset at all; - We reduce overlap of live ranges of `IV` and `IV.next`. They may stop overlapping and it will lead to better register allocation. Even if the overlap will preserve, we are not introducing a new overlap, so it should be a neutral transform (Disabled this patch, will come with follow-up). Currently I've only added support for IVs that get decremented using `usub` intrinsic. We could also support `AddInstr`, however there is some weird interaction with some other transform that may lead to infinite compilation in this case (seems like same transform is done and undone over and over). I need to investigate why it happens, but generally we could do that too. The first part only handles case where this reuse fully elimiates the offset. Differential Revision: https://reviews.llvm.org/D96399 Reviewed By: reames
2021-03-04 06:01:39 +01:00
; CHECK-NEXT: [[SUNKADDR:%.*]] = mul i64 [[MATH]], 4
Return "[Codegenprepare][X86] Use usub with overflow opt for IV increment" The patch did not account for one corner case where cmp does not dominate the loop latch. This patch adds this check, hopefully it's cheap because the CFG does not change during the transform, so DT queries should be executed quickly. If you see compile time slowness from this, please revert. Differential Revision: https://reviews.llvm.org/D96119
2021-02-11 13:25:30 +01:00
; CHECK-NEXT: [[TMP1:%.*]] = bitcast i32* [[P:%.*]] to i8*
; CHECK-NEXT: [[SUNKADDR1:%.*]] = getelementptr i8, i8* [[TMP1]], i64 [[SUNKADDR]]
[X86][CodeGenPrepare] Try to reuse IV's incremented value instead of adding the offset, part 1 While optimizing the memory instruction, we sometimes need to add offset to the value of `IV`. We could avoid doing so if the `IV.next` is already defined at the point of interest. In this case, we may get two possible advantages from this: - If the `IV` step happens to match with the offset, we don't need to add the offset at all; - We reduce overlap of live ranges of `IV` and `IV.next`. They may stop overlapping and it will lead to better register allocation. Even if the overlap will preserve, we are not introducing a new overlap, so it should be a neutral transform (Disabled this patch, will come with follow-up). Currently I've only added support for IVs that get decremented using `usub` intrinsic. We could also support `AddInstr`, however there is some weird interaction with some other transform that may lead to infinite compilation in this case (seems like same transform is done and undone over and over). I need to investigate why it happens, but generally we could do that too. The first part only handles case where this reuse fully elimiates the offset. Differential Revision: https://reviews.llvm.org/D96399 Reviewed By: reames
2021-03-04 06:01:39 +01:00
; CHECK-NEXT: [[TMP2:%.*]] = bitcast i8* [[SUNKADDR1]] to i32*
Return "[Codegenprepare][X86] Use usub with overflow opt for IV increment" The patch did not account for one corner case where cmp does not dominate the loop latch. This patch adds this check, hopefully it's cheap because the CFG does not change during the transform, so DT queries should be executed quickly. If you see compile time slowness from this, please revert. Differential Revision: https://reviews.llvm.org/D96119
2021-02-11 13:25:30 +01:00
; CHECK-NEXT: [[LOADED:%.*]] = load atomic i32, i32* [[TMP2]] unordered, align 4
[Test] Add tests demonstrating missing case of usub with overflow usage The test shows how "usub with overflow" opt gets or does not get applied to increment of IV depending on its code placement, while two cases are semantically equivalent.
2021-02-05 12:27:42 +01:00
; CHECK-NEXT: [[COND_2:%.*]] = icmp eq i32 [[LOADED]], [[X:%.*]]
; CHECK-NEXT: br i1 [[COND_2]], label [[FAILURE:%.*]], label [[LOOP]]
; CHECK: exit:
; CHECK-NEXT: ret i32 -1
; CHECK: failure:
; CHECK-NEXT: unreachable
;
entry:
%scevgep = getelementptr i32, i32* %p, i64 -1
br label %loop
loop: ; preds = %backedge, %entry
%iv = phi i64 [ %iv.next, %backedge ], [ %len, %entry ]
%cond_1 = icmp eq i64 %iv, 0
br i1 %cond_1, label %exit, label %backedge
backedge: ; preds = %loop
%scevgep1 = getelementptr i32, i32* %scevgep, i64 %iv
%loaded = load atomic i32, i32* %scevgep1 unordered, align 4
%cond_2 = icmp eq i32 %loaded, %x
%iv.next = add i64 %iv, -1
br i1 %cond_2, label %failure, label %loop
exit: ; preds = %loop
ret i32 -1
failure: ; preds = %backedge
unreachable
}
[Test] Add negative tests where usub optimization should not apply
2021-02-11 05:41:31 +01:00
declare i1 @use(i64 %x)
declare i1 @some_cond()
; Make sure we do not move the increment below the point where it is used.
define i32 @test_03_neg(i32* %p, i64 %len, i32 %x) {
; CHECK-LABEL: @test_03_neg(
; CHECK-NEXT: entry:
; CHECK-NEXT: br label [[LOOP:%.*]]
; CHECK: loop:
; CHECK-NEXT: [[IV:%.*]] = phi i64 [ [[IV_NEXT:%.*]], [[BACKEDGE:%.*]] ], [ [[LEN:%.*]], [[ENTRY:%.*]] ]
; CHECK-NEXT: [[IV_NEXT]] = add i64 [[IV]], -1
; CHECK-NEXT: [[COND_0:%.*]] = call i1 @use(i64 [[IV_NEXT]])
; CHECK-NEXT: br i1 [[COND_0]], label [[MIDDLE:%.*]], label [[FAILURE:%.*]]
; CHECK: middle:
; CHECK-NEXT: [[COND_1:%.*]] = icmp eq i64 [[IV]], 0
; CHECK-NEXT: br i1 [[COND_1]], label [[EXIT:%.*]], label [[BACKEDGE]]
; CHECK: backedge:
[X86][CodeGenPrepare] Try to reuse IV's incremented value instead of adding the offset, part 1 While optimizing the memory instruction, we sometimes need to add offset to the value of `IV`. We could avoid doing so if the `IV.next` is already defined at the point of interest. In this case, we may get two possible advantages from this: - If the `IV` step happens to match with the offset, we don't need to add the offset at all; - We reduce overlap of live ranges of `IV` and `IV.next`. They may stop overlapping and it will lead to better register allocation. Even if the overlap will preserve, we are not introducing a new overlap, so it should be a neutral transform (Disabled this patch, will come with follow-up). Currently I've only added support for IVs that get decremented using `usub` intrinsic. We could also support `AddInstr`, however there is some weird interaction with some other transform that may lead to infinite compilation in this case (seems like same transform is done and undone over and over). I need to investigate why it happens, but generally we could do that too. The first part only handles case where this reuse fully elimiates the offset. Differential Revision: https://reviews.llvm.org/D96399 Reviewed By: reames
2021-03-04 06:01:39 +01:00
; CHECK-NEXT: [[SUNKADDR:%.*]] = mul i64 [[IV_NEXT]], 4
[Test] Add negative tests where usub optimization should not apply
2021-02-11 05:41:31 +01:00
; CHECK-NEXT: [[TMP0:%.*]] = bitcast i32* [[P:%.*]] to i8*
; CHECK-NEXT: [[SUNKADDR1:%.*]] = getelementptr i8, i8* [[TMP0]], i64 [[SUNKADDR]]
[X86][CodeGenPrepare] Try to reuse IV's incremented value instead of adding the offset, part 1 While optimizing the memory instruction, we sometimes need to add offset to the value of `IV`. We could avoid doing so if the `IV.next` is already defined at the point of interest. In this case, we may get two possible advantages from this: - If the `IV` step happens to match with the offset, we don't need to add the offset at all; - We reduce overlap of live ranges of `IV` and `IV.next`. They may stop overlapping and it will lead to better register allocation. Even if the overlap will preserve, we are not introducing a new overlap, so it should be a neutral transform (Disabled this patch, will come with follow-up). Currently I've only added support for IVs that get decremented using `usub` intrinsic. We could also support `AddInstr`, however there is some weird interaction with some other transform that may lead to infinite compilation in this case (seems like same transform is done and undone over and over). I need to investigate why it happens, but generally we could do that too. The first part only handles case where this reuse fully elimiates the offset. Differential Revision: https://reviews.llvm.org/D96399 Reviewed By: reames
2021-03-04 06:01:39 +01:00
; CHECK-NEXT: [[TMP1:%.*]] = bitcast i8* [[SUNKADDR1]] to i32*
[Test] Add negative tests where usub optimization should not apply
2021-02-11 05:41:31 +01:00
; CHECK-NEXT: [[LOADED:%.*]] = load atomic i32, i32* [[TMP1]] unordered, align 4
; CHECK-NEXT: [[COND_2:%.*]] = icmp eq i32 [[LOADED]], [[X:%.*]]
; CHECK-NEXT: br i1 [[COND_2]], label [[FAILURE]], label [[LOOP]]
; CHECK: exit:
; CHECK-NEXT: ret i32 -1
; CHECK: failure:
; CHECK-NEXT: unreachable
;
entry:
%scevgep = getelementptr i32, i32* %p, i64 -1
br label %loop
loop: ; preds = %backedge, %entry
%iv = phi i64 [ %iv.next, %backedge ], [ %len, %entry ]
%iv.next = add i64 %iv, -1
%cond_0 = call i1 @use(i64 %iv.next)
br i1 %cond_0, label %middle, label %failure
middle:
%cond_1 = icmp eq i64 %iv, 0
br i1 %cond_1, label %exit, label %backedge
backedge: ; preds = %loop
%scevgep1 = getelementptr i32, i32* %scevgep, i64 %iv
%loaded = load atomic i32, i32* %scevgep1 unordered, align 4
%cond_2 = icmp eq i32 %loaded, %x
br i1 %cond_2, label %failure, label %loop
exit: ; preds = %loop
ret i32 -1
failure: ; preds = %backedge
unreachable
}
define i32 @test_04_neg(i32* %p, i64 %len, i32 %x) {
; CHECK-LABEL: @test_04_neg(
; CHECK-NEXT: entry:
; CHECK-NEXT: br label [[LOOP:%.*]]
; CHECK: loop:
; CHECK-NEXT: [[IV:%.*]] = phi i64 [ [[IV_NEXT:%.*]], [[BACKEDGE:%.*]] ], [ [[LEN:%.*]], [[ENTRY:%.*]] ]
; CHECK-NEXT: br label [[INNER:%.*]]
; CHECK: inner:
; CHECK-NEXT: [[COND_1:%.*]] = icmp eq i64 [[IV]], 0
; CHECK-NEXT: br i1 [[COND_1]], label [[INNER_BACKEDGE:%.*]], label [[EXIT:%.*]]
; CHECK: inner_backedge:
; CHECK-NEXT: [[COND_INNER:%.*]] = call i1 @some_cond()
; CHECK-NEXT: br i1 [[COND_INNER]], label [[INNER]], label [[BACKEDGE]]
; CHECK: backedge:
; CHECK-NEXT: [[SUNKADDR:%.*]] = mul i64 [[IV]], 4
; CHECK-NEXT: [[TMP0:%.*]] = bitcast i32* [[P:%.*]] to i8*
; CHECK-NEXT: [[SUNKADDR1:%.*]] = getelementptr i8, i8* [[TMP0]], i64 [[SUNKADDR]]
; CHECK-NEXT: [[SUNKADDR2:%.*]] = getelementptr i8, i8* [[SUNKADDR1]], i64 -4
; CHECK-NEXT: [[TMP1:%.*]] = bitcast i8* [[SUNKADDR2]] to i32*
; CHECK-NEXT: [[LOADED:%.*]] = load atomic i32, i32* [[TMP1]] unordered, align 4
; CHECK-NEXT: [[COND_2:%.*]] = icmp eq i32 [[LOADED]], [[X:%.*]]
; CHECK-NEXT: [[IV_NEXT]] = add i64 [[IV]], -1
; CHECK-NEXT: br i1 [[COND_2]], label [[FAILURE:%.*]], label [[LOOP]]
; CHECK: exit:
; CHECK-NEXT: ret i32 -1
; CHECK: failure:
; CHECK-NEXT: unreachable
;
entry:
%scevgep = getelementptr i32, i32* %p, i64 -1
br label %loop
loop:
%iv = phi i64 [ %iv.next, %backedge ], [ %len, %entry ]
br label %inner
inner:
%cond_1 = icmp eq i64 %iv, 0
br i1 %cond_1, label %inner_backedge, label %exit
inner_backedge:
%cond_inner = call i1 @some_cond()
br i1 %cond_inner, label %inner, label %backedge
backedge:
%scevgep1 = getelementptr i32, i32* %scevgep, i64 %iv
%loaded = load atomic i32, i32* %scevgep1 unordered, align 4
%cond_2 = icmp eq i32 %loaded, %x
%iv.next = add i64 %iv, -1
br i1 %cond_2, label %failure, label %loop
exit:
ret i32 -1
failure:
unreachable
}
[Test] Add test that exposed failure on reverted patch in codegen
2021-02-11 13:08:55 +01:00
; Here Cmp does not dominate latch.
define i32 @test_05_neg(i32* %p, i64 %len, i32 %x, i1 %cond) {
; CHECK-LABEL: @test_05_neg(
; CHECK-NEXT: entry:
; CHECK-NEXT: br label [[LOOP:%.*]]
; CHECK: loop:
; CHECK-NEXT: [[IV:%.*]] = phi i64 [ [[IV_NEXT:%.*]], [[BACKEDGE:%.*]] ], [ [[LEN:%.*]], [[ENTRY:%.*]] ]
; CHECK-NEXT: [[IV_NEXT]] = add i64 [[IV]], -1
; CHECK-NEXT: br i1 [[COND:%.*]], label [[IF_TRUE:%.*]], label [[BACKEDGE]]
; CHECK: if.true:
; CHECK-NEXT: [[COND_1:%.*]] = icmp eq i64 [[IV]], 0
; CHECK-NEXT: br i1 [[COND_1]], label [[EXIT:%.*]], label [[BACKEDGE]]
; CHECK: backedge:
[X86][CodeGenPrepare] Try to reuse IV's incremented value instead of adding the offset, part 1 While optimizing the memory instruction, we sometimes need to add offset to the value of `IV`. We could avoid doing so if the `IV.next` is already defined at the point of interest. In this case, we may get two possible advantages from this: - If the `IV` step happens to match with the offset, we don't need to add the offset at all; - We reduce overlap of live ranges of `IV` and `IV.next`. They may stop overlapping and it will lead to better register allocation. Even if the overlap will preserve, we are not introducing a new overlap, so it should be a neutral transform (Disabled this patch, will come with follow-up). Currently I've only added support for IVs that get decremented using `usub` intrinsic. We could also support `AddInstr`, however there is some weird interaction with some other transform that may lead to infinite compilation in this case (seems like same transform is done and undone over and over). I need to investigate why it happens, but generally we could do that too. The first part only handles case where this reuse fully elimiates the offset. Differential Revision: https://reviews.llvm.org/D96399 Reviewed By: reames
2021-03-04 06:01:39 +01:00
; CHECK-NEXT: [[SUNKADDR:%.*]] = mul i64 [[IV_NEXT]], 4
[Test] Add test that exposed failure on reverted patch in codegen
2021-02-11 13:08:55 +01:00
; CHECK-NEXT: [[TMP0:%.*]] = bitcast i32* [[P:%.*]] to i8*
; CHECK-NEXT: [[SUNKADDR1:%.*]] = getelementptr i8, i8* [[TMP0]], i64 [[SUNKADDR]]
[X86][CodeGenPrepare] Try to reuse IV's incremented value instead of adding the offset, part 1 While optimizing the memory instruction, we sometimes need to add offset to the value of `IV`. We could avoid doing so if the `IV.next` is already defined at the point of interest. In this case, we may get two possible advantages from this: - If the `IV` step happens to match with the offset, we don't need to add the offset at all; - We reduce overlap of live ranges of `IV` and `IV.next`. They may stop overlapping and it will lead to better register allocation. Even if the overlap will preserve, we are not introducing a new overlap, so it should be a neutral transform (Disabled this patch, will come with follow-up). Currently I've only added support for IVs that get decremented using `usub` intrinsic. We could also support `AddInstr`, however there is some weird interaction with some other transform that may lead to infinite compilation in this case (seems like same transform is done and undone over and over). I need to investigate why it happens, but generally we could do that too. The first part only handles case where this reuse fully elimiates the offset. Differential Revision: https://reviews.llvm.org/D96399 Reviewed By: reames
2021-03-04 06:01:39 +01:00
; CHECK-NEXT: [[TMP1:%.*]] = bitcast i8* [[SUNKADDR1]] to i32*
[Test] Add test that exposed failure on reverted patch in codegen
2021-02-11 13:08:55 +01:00
; CHECK-NEXT: [[LOADED:%.*]] = load atomic i32, i32* [[TMP1]] unordered, align 4
; CHECK-NEXT: [[COND_2:%.*]] = icmp eq i32 [[LOADED]], [[X:%.*]]
; CHECK-NEXT: br i1 [[COND_2]], label [[FAILURE:%.*]], label [[LOOP]]
; CHECK: exit:
; CHECK-NEXT: ret i32 -1
; CHECK: failure:
; CHECK-NEXT: unreachable
;
entry:
%scevgep = getelementptr i32, i32* %p, i64 -1
br label %loop
loop: ; preds = %backedge, %entry
%iv = phi i64 [ %iv.next, %backedge ], [ %len, %entry ]
%iv.next = add i64 %iv, -1
br i1 %cond, label %if.true, label %backedge
if.true:
%cond_1 = icmp eq i64 %iv, 0
br i1 %cond_1, label %exit, label %backedge
backedge: ; preds = %loop
%scevgep1 = getelementptr i32, i32* %scevgep, i64 %iv
%loaded = load atomic i32, i32* %scevgep1 unordered, align 4
%cond_2 = icmp eq i32 %loaded, %x
br i1 %cond_2, label %failure, label %loop
exit: ; preds = %loop
ret i32 -1
failure: ; preds = %backedge
unreachable
}
[tests] precommit test for an upcoming change
2021-03-09 20:39:10 +01:00
; test_01, but with an additional use of %iv.next outside the loop
define i32 @test_06(i32* %p, i64 %len, i32 %x) {
; CHECK-LABEL: @test_06(
; CHECK-NEXT: entry:
; CHECK-NEXT: br label [[LOOP:%.*]]
; CHECK: loop:
[cgp] improve robustness of uadd/usub transforms LSR prefers to schedule iv increments just before the latch. The recent 80511565 broadened this to moving increments in the original IR. This pointed out a robustness problem with the CGP transform. When we have a use of an induction increment outside of the loop (we canonicalize away from this form, but it happens e.g. unanalyzeable loops) we'd avoid performing the uadd/usub transform. Interestingly, all of these involve moving the increment closer to it's operands, so there's no concern about dominating all uses. We can handle that case cheaply, resulting in a more robust transform.
2021-03-09 20:44:43 +01:00
; CHECK-NEXT: [[IV:%.*]] = phi i64 [ [[MATH:%.*]], [[BACKEDGE:%.*]] ], [ [[LEN:%.*]], [[ENTRY:%.*]] ]
; CHECK-NEXT: [[TMP0:%.*]] = call { i64, i1 } @llvm.usub.with.overflow.i64(i64 [[IV]], i64 1)
; CHECK-NEXT: [[MATH]] = extractvalue { i64, i1 } [[TMP0]], 0
; CHECK-NEXT: [[OV:%.*]] = extractvalue { i64, i1 } [[TMP0]], 1
; CHECK-NEXT: br i1 [[OV]], label [[EXIT:%.*]], label [[BACKEDGE]]
[tests] precommit test for an upcoming change
2021-03-09 20:39:10 +01:00
; CHECK: backedge:
[cgp] improve robustness of uadd/usub transforms LSR prefers to schedule iv increments just before the latch. The recent 80511565 broadened this to moving increments in the original IR. This pointed out a robustness problem with the CGP transform. When we have a use of an induction increment outside of the loop (we canonicalize away from this form, but it happens e.g. unanalyzeable loops) we'd avoid performing the uadd/usub transform. Interestingly, all of these involve moving the increment closer to it's operands, so there's no concern about dominating all uses. We can handle that case cheaply, resulting in a more robust transform.
2021-03-09 20:44:43 +01:00
; CHECK-NEXT: [[SUNKADDR:%.*]] = mul i64 [[MATH]], 4
; CHECK-NEXT: [[TMP1:%.*]] = bitcast i32* [[P:%.*]] to i8*
; CHECK-NEXT: [[SUNKADDR1:%.*]] = getelementptr i8, i8* [[TMP1]], i64 [[SUNKADDR]]
; CHECK-NEXT: [[TMP2:%.*]] = bitcast i8* [[SUNKADDR1]] to i32*
; CHECK-NEXT: [[LOADED:%.*]] = load atomic i32, i32* [[TMP2]] unordered, align 4
[tests] precommit test for an upcoming change
2021-03-09 20:39:10 +01:00
; CHECK-NEXT: [[COND_2:%.*]] = icmp eq i32 [[LOADED]], [[X:%.*]]
; CHECK-NEXT: br i1 [[COND_2]], label [[FAILURE:%.*]], label [[LOOP]]
; CHECK: exit:
; CHECK-NEXT: ret i32 -1
; CHECK: failure:
[cgp] improve robustness of uadd/usub transforms LSR prefers to schedule iv increments just before the latch. The recent 80511565 broadened this to moving increments in the original IR. This pointed out a robustness problem with the CGP transform. When we have a use of an induction increment outside of the loop (we canonicalize away from this form, but it happens e.g. unanalyzeable loops) we'd avoid performing the uadd/usub transform. Interestingly, all of these involve moving the increment closer to it's operands, so there's no concern about dominating all uses. We can handle that case cheaply, resulting in a more robust transform.
2021-03-09 20:44:43 +01:00
; CHECK-NEXT: [[TRUNC:%.*]] = trunc i64 [[MATH]] to i32
[tests] precommit test for an upcoming change
2021-03-09 20:39:10 +01:00
; CHECK-NEXT: ret i32 [[TRUNC]]
;
entry:
%scevgep = getelementptr i32, i32* %p, i64 -1
br label %loop
loop: ; preds = %backedge, %entry
%iv = phi i64 [ %iv.next, %backedge ], [ %len, %entry ]
%cond_1 = icmp eq i64 %iv, 0
br i1 %cond_1, label %exit, label %backedge
backedge: ; preds = %loop
%scevgep1 = getelementptr i32, i32* %scevgep, i64 %iv
%loaded = load atomic i32, i32* %scevgep1 unordered, align 4
%iv.next = add i64 %iv, -1
%cond_2 = icmp eq i32 %loaded, %x
br i1 %cond_2, label %failure, label %loop
exit:
ret i32 -1
failure:
%trunc = trunc i64 %iv.next to i32
ret i32 %trunc
}
; Extra use outside loop which prevents us moving the increment to the cmp
define i32 @test_07_neg(i32* %p, i64 %len, i32 %x) {
; CHECK-LABEL: @test_07_neg(
; CHECK-NEXT: entry:
; CHECK-NEXT: br label [[LOOP:%.*]]
; CHECK: loop:
; CHECK-NEXT: [[IV:%.*]] = phi i64 [ [[IV_NEXT:%.*]], [[BACKEDGE:%.*]] ], [ [[LEN:%.*]], [[ENTRY:%.*]] ]
; CHECK-NEXT: [[IV_NEXT]] = add i64 [[IV]], -1
; CHECK-NEXT: [[SUNKADDR:%.*]] = mul i64 [[IV_NEXT]], 4
; CHECK-NEXT: [[TMP0:%.*]] = bitcast i32* [[P:%.*]] to i8*
; CHECK-NEXT: [[SUNKADDR1:%.*]] = getelementptr i8, i8* [[TMP0]], i64 [[SUNKADDR]]
; CHECK-NEXT: [[TMP1:%.*]] = bitcast i8* [[SUNKADDR1]] to i32*
; CHECK-NEXT: [[LOADED:%.*]] = load atomic i32, i32* [[TMP1]] unordered, align 4
; CHECK-NEXT: [[COND_2:%.*]] = icmp eq i32 [[LOADED]], [[X:%.*]]
; CHECK-NEXT: br i1 [[COND_2]], label [[FAILURE:%.*]], label [[BACKEDGE]]
; CHECK: backedge:
; CHECK-NEXT: [[COND_1:%.*]] = icmp eq i64 [[IV]], 0
; CHECK-NEXT: br i1 [[COND_1]], label [[EXIT:%.*]], label [[LOOP]]
; CHECK: exit:
; CHECK-NEXT: ret i32 -1
; CHECK: failure:
; CHECK-NEXT: [[TRUNC:%.*]] = trunc i64 [[IV_NEXT]] to i32
; CHECK-NEXT: ret i32 [[TRUNC]]
;
entry:
%scevgep = getelementptr i32, i32* %p, i64 -1
br label %loop
loop:
%iv = phi i64 [ %iv.next, %backedge ], [ %len, %entry ]
%iv.next = add i64 %iv, -1
%scevgep1 = getelementptr i32, i32* %scevgep, i64 %iv
%loaded = load atomic i32, i32* %scevgep1 unordered, align 4
%cond_2 = icmp eq i32 %loaded, %x
br i1 %cond_2, label %failure, label %backedge
backedge:
%cond_1 = icmp eq i64 %iv, 0
br i1 %cond_1, label %exit, label %loop
exit:
ret i32 -1
failure:
%trunc = trunc i64 %iv.next to i32
ret i32 %trunc
}
Reference in New Issue Copy Permalink