maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/Transforms/InstCombine/statepoint-iter.ll

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

57 lines
2.2 KiB
LLVM
Raw Normal View History

[InstCombine] Handle gc.relocate(null) in one iteration InstCombine adds users of transformed instruction to working list to process on the same iteration. However gc.relocate may have a hidden user (next gc.relocate) which is connected through gc.statepoint intrinsic and there is no direct def-use chain between them. In this case if the next gc.relocation is already processed it will not be added to worklist and will not be able to be processed on the same iteration. Let's we have the following case: A = gc.relocate(null) B = statepoint(A) C = gc.relocate(B, hidden(A)) If C is already considered then after replacement of A with null, statepoint B instruction will be added to the queue but not C. C can be processed only on the next iteration. If the chain of relocation is pretty long the many iteration may be required. This change is to reduce the number of iteration to meet the latest changes related to reducing infinite loop threshold. This is a quick (not best) fix. In the follow up patches I plan to move gc relocation handling into statepoint handler. This should also help to remove unused gc live entries in statepoint bundle. Reviewers: reames, dantrushin Reviewed By: reames Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D75598
2020-08-12 15:25:18 +08:00
; RUN: opt < %s -instcombine -instcombine-max-iterations=1 -S | FileCheck %s
; These tests check the optimizations specific to
; pointers being relocated at a statepoint.
declare void @func()
define i1 @test_null(i1 %cond) gc "statepoint-example" {
entry:
br i1 %cond, label %left, label %right
right:
br label %merge
left:
Remove inline gc arguments from statepoints The "gc-live" operand bundles were recently added, and all tests have been updated to use that format. A migration period was provided, though it's worth noting these intrinsics are experimental, so formally there is no compatibile requirement. This is an extension to a96fc46. "gc-live" hadn't been implemented at the point that patch was initially posted.
2020-08-15 10:42:18 +08:00
%safepoint_token = tail call token (i64, i32, void ()*, i32, i32, ...) @llvm.experimental.gc.statepoint.p0f_isVoidf(i64 0, i32 0, void ()* @func, i32 0, i32 0, i32 0, i32 0) ["gc-live" (i32* null)]
%pnew = call i32* @llvm.experimental.gc.relocate.p1i32(token %safepoint_token, i32 0, i32 0)
[InstCombine] Handle gc.relocate(null) in one iteration InstCombine adds users of transformed instruction to working list to process on the same iteration. However gc.relocate may have a hidden user (next gc.relocate) which is connected through gc.statepoint intrinsic and there is no direct def-use chain between them. In this case if the next gc.relocation is already processed it will not be added to worklist and will not be able to be processed on the same iteration. Let's we have the following case: A = gc.relocate(null) B = statepoint(A) C = gc.relocate(B, hidden(A)) If C is already considered then after replacement of A with null, statepoint B instruction will be added to the queue but not C. C can be processed only on the next iteration. If the chain of relocation is pretty long the many iteration may be required. This change is to reduce the number of iteration to meet the latest changes related to reducing infinite loop threshold. This is a quick (not best) fix. In the follow up patches I plan to move gc relocation handling into statepoint handler. This should also help to remove unused gc live entries in statepoint bundle. Reviewers: reames, dantrushin Reviewed By: reames Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D75598
2020-08-12 15:25:18 +08:00
br label %merge
merge:
%pnew_phi = phi i32* [null, %right], [%pnew, %left]
Remove inline gc arguments from statepoints The "gc-live" operand bundles were recently added, and all tests have been updated to use that format. A migration period was provided, though it's worth noting these intrinsics are experimental, so formally there is no compatibile requirement. This is an extension to a96fc46. "gc-live" hadn't been implemented at the point that patch was initially posted.
2020-08-15 10:42:18 +08:00
%safepoint_token2 = tail call token (i64, i32, void ()*, i32, i32, ...) @llvm.experimental.gc.statepoint.p0f_isVoidf(i64 0, i32 0, void ()* @func, i32 0, i32 0, i32 0, i32 0) ["gc-live" (i32* %pnew_phi)]
%pnew2 = call i32* @llvm.experimental.gc.relocate.p1i32(token %safepoint_token2, i32 0, i32 0)
[InstCombine] Handle gc.relocate(null) in one iteration InstCombine adds users of transformed instruction to working list to process on the same iteration. However gc.relocate may have a hidden user (next gc.relocate) which is connected through gc.statepoint intrinsic and there is no direct def-use chain between them. In this case if the next gc.relocation is already processed it will not be added to worklist and will not be able to be processed on the same iteration. Let's we have the following case: A = gc.relocate(null) B = statepoint(A) C = gc.relocate(B, hidden(A)) If C is already considered then after replacement of A with null, statepoint B instruction will be added to the queue but not C. C can be processed only on the next iteration. If the chain of relocation is pretty long the many iteration may be required. This change is to reduce the number of iteration to meet the latest changes related to reducing infinite loop threshold. This is a quick (not best) fix. In the follow up patches I plan to move gc relocation handling into statepoint handler. This should also help to remove unused gc live entries in statepoint bundle. Reviewers: reames, dantrushin Reviewed By: reames Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D75598
2020-08-12 15:25:18 +08:00
%cmp = icmp eq i32* %pnew2, null
ret i1 %cmp
; CHECK-LABEL: test_null
; CHECK-NOT: %pnew
; CHECK-NOT: %pnew2
; CHECK: ret i1 true
}
define i32* @test_undef(i1 %cond) gc "statepoint-example" {
entry:
br i1 %cond, label %left, label %right
right:
br label %merge
left:
Remove inline gc arguments from statepoints The "gc-live" operand bundles were recently added, and all tests have been updated to use that format. A migration period was provided, though it's worth noting these intrinsics are experimental, so formally there is no compatibile requirement. This is an extension to a96fc46. "gc-live" hadn't been implemented at the point that patch was initially posted.
2020-08-15 10:42:18 +08:00
%safepoint_token = tail call token (i64, i32, void ()*, i32, i32, ...) @llvm.experimental.gc.statepoint.p0f_isVoidf(i64 0, i32 0, void ()* @func, i32 0, i32 0, i32 0, i32 0) ["gc-live" (i32* undef)]
%pnew = call i32* @llvm.experimental.gc.relocate.p1i32(token %safepoint_token, i32 0, i32 0)
[InstCombine] Handle gc.relocate(null) in one iteration InstCombine adds users of transformed instruction to working list to process on the same iteration. However gc.relocate may have a hidden user (next gc.relocate) which is connected through gc.statepoint intrinsic and there is no direct def-use chain between them. In this case if the next gc.relocation is already processed it will not be added to worklist and will not be able to be processed on the same iteration. Let's we have the following case: A = gc.relocate(null) B = statepoint(A) C = gc.relocate(B, hidden(A)) If C is already considered then after replacement of A with null, statepoint B instruction will be added to the queue but not C. C can be processed only on the next iteration. If the chain of relocation is pretty long the many iteration may be required. This change is to reduce the number of iteration to meet the latest changes related to reducing infinite loop threshold. This is a quick (not best) fix. In the follow up patches I plan to move gc relocation handling into statepoint handler. This should also help to remove unused gc live entries in statepoint bundle. Reviewers: reames, dantrushin Reviewed By: reames Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D75598
2020-08-12 15:25:18 +08:00
br label %merge
merge:
%pnew_phi = phi i32* [undef, %right], [%pnew, %left]
Remove inline gc arguments from statepoints The "gc-live" operand bundles were recently added, and all tests have been updated to use that format. A migration period was provided, though it's worth noting these intrinsics are experimental, so formally there is no compatibile requirement. This is an extension to a96fc46. "gc-live" hadn't been implemented at the point that patch was initially posted.
2020-08-15 10:42:18 +08:00
%safepoint_token2 = tail call token (i64, i32, void ()*, i32, i32, ...) @llvm.experimental.gc.statepoint.p0f_isVoidf(i64 0, i32 0, void ()* @func, i32 0, i32 0, i32 0, i32 0) ["gc-live" (i32* %pnew_phi)]
%pnew2 = call i32* @llvm.experimental.gc.relocate.p1i32(token %safepoint_token2, i32 0, i32 0)
[InstCombine] Handle gc.relocate(null) in one iteration InstCombine adds users of transformed instruction to working list to process on the same iteration. However gc.relocate may have a hidden user (next gc.relocate) which is connected through gc.statepoint intrinsic and there is no direct def-use chain between them. In this case if the next gc.relocation is already processed it will not be added to worklist and will not be able to be processed on the same iteration. Let's we have the following case: A = gc.relocate(null) B = statepoint(A) C = gc.relocate(B, hidden(A)) If C is already considered then after replacement of A with null, statepoint B instruction will be added to the queue but not C. C can be processed only on the next iteration. If the chain of relocation is pretty long the many iteration may be required. This change is to reduce the number of iteration to meet the latest changes related to reducing infinite loop threshold. This is a quick (not best) fix. In the follow up patches I plan to move gc relocation handling into statepoint handler. This should also help to remove unused gc live entries in statepoint bundle. Reviewers: reames, dantrushin Reviewed By: reames Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D75598
2020-08-12 15:25:18 +08:00
ret i32* %pnew2
; CHECK-LABEL: test_undef
; CHECK-NOT: %pnew
; CHECK-NOT: %pnew2
; CHECK: ret i32* undef
}
declare token @llvm.experimental.gc.statepoint.p0f_isVoidf(i64, i32, void ()*, i32, i32, ...)
declare i32* @llvm.experimental.gc.relocate.p1i32(token, i32, i32)