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/Attributor/range.ll

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

1038 lines
40 KiB
LLVM
Raw Normal View History

[Attributor] Use fine-grained liveness in all helpers We used coarse-grained liveness before, thus we looked if the instruction was executed, but we did not use fine-grained liveness, hence if the instruction was needed or could be deleted even if the surrounding ones are live. This patches introduces this level of liveness checks together with other liveness queries, e.g., for uses. For more control we enforce that all liveness queries go through the Attributor. Test have been adjusted to reflect the changes or augmented to prevent deletion of the parts we want to check. Reviewed By: sstefan1 Differential Revision: https://reviews.llvm.org/D73313
2020-01-12 15:09:22 +08:00
; NOTE: Assertions have been autogenerated by utils/update_test_checks.py UTC_ARGS: --function-signature --scrub-attributes
[Attributor] Remove dependence edges eagerly If we have a dependence between an abstract attribute A to an abstract attribute B such hat changes in A should trigger an update of B, we do not need to keep the dependence around once the update was triggered. If the dependence is still required the update will reinsert it into the dependence map, if it is not we avoid triggering B in the future. This replaces the "recompute interval" mechanism we used before to prune stale dependences. Number of required iterations is generally down, compile time for the module pass (not really the CGSCC pass) is down quite a bit. There is one test change which looks like an artifact in the undefined behavior AA that needs to be looked at.
2020-04-22 02:57:19 +08:00
; RUN: opt -attributor -attributor-manifest-internal -attributor-max-iterations-verify -attributor-annotate-decl-cs -attributor-max-iterations=8 -S < %s | FileCheck %s --check-prefixes=CHECK,NOT_CGSCC_NPM,NOT_CGSCC_OPM,NOT_TUNIT_NPM,IS__TUNIT____,IS________OPM,IS__TUNIT_OPM
; RUN: opt -aa-pipeline=basic-aa -passes=attributor -attributor-manifest-internal -attributor-max-iterations-verify -attributor-annotate-decl-cs -attributor-max-iterations=15 -S < %s | FileCheck %s --check-prefixes=CHECK,NOT_CGSCC_OPM,NOT_CGSCC_NPM,NOT_TUNIT_OPM,IS__TUNIT____,IS________NPM,IS__TUNIT_NPM
[Attributor][NFC] Remove obsolete option from tests Since D76871 it is sufficient to run `opt -atributor` or `-attributor-cgscc`.
2020-04-18 10:09:16 +08:00
; RUN: opt -attributor-cgscc -attributor-manifest-internal -attributor-annotate-decl-cs -S < %s | FileCheck %s --check-prefixes=CHECK,NOT_TUNIT_NPM,NOT_TUNIT_OPM,NOT_CGSCC_NPM,IS__CGSCC____,IS________OPM,IS__CGSCC_OPM
; RUN: opt -aa-pipeline=basic-aa -passes=attributor-cgscc -attributor-manifest-internal -attributor-annotate-decl-cs -S < %s | FileCheck %s --check-prefixes=CHECK,NOT_TUNIT_NPM,NOT_TUNIT_OPM,NOT_CGSCC_OPM,IS__CGSCC____,IS________NPM,IS__CGSCC_NPM
[Attributor][Tests] Run the CGSCC versions on the range.ll test
2020-02-10 09:08:19 +08:00
; FIXME: CGSCC is not looking at callees and calleers even though it could be allowed.
[Attributor] AAValueConstantRange: Value range analysis using constant range Summary: This patch introduces `AAValueConstantRange`, which answers a possible range for integer value in a specific program point. One of the motivations is propagating existing `range` metadata. (I think we need to change the situation that `range` metadata cannot be put to Argument). The state is a tuple of `ConstantRange` and it is initialized to (known, assumed) = ([-∞, +∞], empty). Currently, AAValueConstantRange is created in `getAssumedConstant` method when `AAValueSimplify` returns `nullptr`(worst state). Supported - BinaryOperator(add, sub, ...) - CmpInst(icmp eq, ...) - !range metadata `AAValueConstantRange` is not intended to extend to polyhedral range value analysis. Reviewers: jdoerfert, sstefan1 Reviewed By: jdoerfert Subscribers: phosek, davezarzycki, baziotis, hiraditya, javed.absar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71620
2020-01-15 14:25:52 +08:00
define i32 @test0(i32* %p) {
; CHECK-LABEL: define {{[^@]+}}@test0
[Attributor] Derive better alignment for accessed pointers Use DL & ABI information for better alignment deduction, e.g., if a type is accessed and the ABI specifies an alignment requirement for such an access we can use it. This is based on a patch by @lebedev.ri and inspired by getBaseAlign in Loads.cpp. Depends on D76673. Reviewed By: lebedev.ri Differential Revision: https://reviews.llvm.org/D76674
2020-04-02 10:46:03 +08:00
; CHECK-SAME: (i32* nocapture nofree nonnull readonly align 4 dereferenceable(4) [[P:%.*]])
; CHECK-NEXT: [[A:%.*]] = load i32, i32* [[P]], align 4, !range !0
[Attributor] AAValueConstantRange: Value range analysis using constant range Summary: This patch introduces `AAValueConstantRange`, which answers a possible range for integer value in a specific program point. One of the motivations is propagating existing `range` metadata. (I think we need to change the situation that `range` metadata cannot be put to Argument). The state is a tuple of `ConstantRange` and it is initialized to (known, assumed) = ([-∞, +∞], empty). Currently, AAValueConstantRange is created in `getAssumedConstant` method when `AAValueSimplify` returns `nullptr`(worst state). Supported - BinaryOperator(add, sub, ...) - CmpInst(icmp eq, ...) - !range metadata `AAValueConstantRange` is not intended to extend to polyhedral range value analysis. Reviewers: jdoerfert, sstefan1 Reviewed By: jdoerfert Subscribers: phosek, davezarzycki, baziotis, hiraditya, javed.absar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71620
2020-01-15 14:25:52 +08:00
; CHECK-NEXT: ret i32 [[A]]
;
%a = load i32, i32* %p, !range !0
ret i32 %a
}
define i32 @test0-range-check(i32* %p) {
[Attributor] Unify testing (=updates,prefixes,run configurations,...) When the Attributor was created the test update scripts were not well suited to deal with the challenges of IR attribute checking. This partially improved. Since then we also added three additional configurations that need testing; in total we now have the following four: { TUNIT, CGSCC } x { old pass manager (OPM), new pass manager (NPM) } Finally, the number of developers and tests grew rapidly (partially due to the addition of ArgumentPromotion and IPConstantProp tests), which resulted in tests only being run in some configurations, different prefixes being used, and different "styles" of checks being used. Due to the above reasons I believed we needed to take another look at the test update scripts. While we started to use them, via UTC_ARGS: --enable/disable, the other problems remained. To improve the testing situation for *all* configurations, to simplify future updates to the test, and to help identify subtle effects of future changes, we now use the test update scripts for (almost) all Attributor tests. An exhaustive prefix list minimizes the number of check lines and makes it easy to identify and compare configurations. Tests have been adjusted in the process but we tried to keep their intend unchanged. Reviewed By: sstefan1 Differential Revision: https://reviews.llvm.org/D76588
2020-04-09 08:04:57 +08:00
; IS__TUNIT____-LABEL: define {{[^@]+}}@test0-range-check
; IS__TUNIT____-SAME: (i32* nocapture nofree readonly align 4 [[P:%.*]])
; IS__TUNIT____-NEXT: [[A:%.*]] = tail call i32 @test0(i32* nocapture nofree readonly align 4 [[P]]) #4, !range !0
; IS__TUNIT____-NEXT: ret i32 [[A]]
[Attributor][Tests] Run the CGSCC versions on the range.ll test
2020-02-10 09:08:19 +08:00
;
[Attributor] Unify testing (=updates,prefixes,run configurations,...) When the Attributor was created the test update scripts were not well suited to deal with the challenges of IR attribute checking. This partially improved. Since then we also added three additional configurations that need testing; in total we now have the following four: { TUNIT, CGSCC } x { old pass manager (OPM), new pass manager (NPM) } Finally, the number of developers and tests grew rapidly (partially due to the addition of ArgumentPromotion and IPConstantProp tests), which resulted in tests only being run in some configurations, different prefixes being used, and different "styles" of checks being used. Due to the above reasons I believed we needed to take another look at the test update scripts. While we started to use them, via UTC_ARGS: --enable/disable, the other problems remained. To improve the testing situation for *all* configurations, to simplify future updates to the test, and to help identify subtle effects of future changes, we now use the test update scripts for (almost) all Attributor tests. An exhaustive prefix list minimizes the number of check lines and makes it easy to identify and compare configurations. Tests have been adjusted in the process but we tried to keep their intend unchanged. Reviewed By: sstefan1 Differential Revision: https://reviews.llvm.org/D76588
2020-04-09 08:04:57 +08:00
; IS__CGSCC____-LABEL: define {{[^@]+}}@test0-range-check
; IS__CGSCC____-SAME: (i32* nocapture nofree nonnull readonly align 4 dereferenceable(4) [[P:%.*]])
; IS__CGSCC____-NEXT: [[A:%.*]] = tail call i32 @test0(i32* nocapture nofree nonnull readonly align 4 dereferenceable(4) [[P]])
; IS__CGSCC____-NEXT: ret i32 [[A]]
[Attributor][FIX] Make check lines explicit There is a bug in `update_test_checks.py` that combines check lines it should not. For now we unbreak the bots by making all possibilities explicit.
2020-02-10 15:31:20 +08:00
;
[Attributor] AAValueConstantRange: Value range analysis using constant range Summary: This patch introduces `AAValueConstantRange`, which answers a possible range for integer value in a specific program point. One of the motivations is propagating existing `range` metadata. (I think we need to change the situation that `range` metadata cannot be put to Argument). The state is a tuple of `ConstantRange` and it is initialized to (known, assumed) = ([-∞, +∞], empty). Currently, AAValueConstantRange is created in `getAssumedConstant` method when `AAValueSimplify` returns `nullptr`(worst state). Supported - BinaryOperator(add, sub, ...) - CmpInst(icmp eq, ...) - !range metadata `AAValueConstantRange` is not intended to extend to polyhedral range value analysis. Reviewers: jdoerfert, sstefan1 Reviewed By: jdoerfert Subscribers: phosek, davezarzycki, baziotis, hiraditya, javed.absar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71620
2020-01-15 14:25:52 +08:00
%a = tail call i32 @test0(i32* %p)
ret i32 %a
}
declare void @use3-dummy(i1, i1, i1)
define void @use3(i1, i1, i1) {
; CHECK-LABEL: define {{[^@]+}}@use3
; CHECK-SAME: (i1 [[TMP0:%.*]], i1 [[TMP1:%.*]], i1 [[TMP2:%.*]])
; CHECK-NEXT: tail call void @use3-dummy(i1 [[TMP0]], i1 [[TMP1]], i1 [[TMP2]])
; CHECK-NEXT: ret void
;
tail call void @use3-dummy(i1 %0, i1 %1, i1 %2)
ret void
}
; TEST0 icmp test
define void @test0-icmp-check(i32* %p){
Temporarily revert "[Attributor] Unify testing (=updates,...)" This patch reverts the 2 patches below, as on most systems the disabled tests actually pass and that causes most bots to be red, including http://green.lab.llvm.org/green/job/clang-stage1-RA/8541/ http://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-expensive/15646/ http://lab.llvm.org:8011/builders/clang-ppc64le-linux-lnt/builds/23690 http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/16751 * [Attributor] Disable three tests until the SCC update bug was fixed commit 2ae1a76c27295370d552f57352508b7af4dba791. * [Attributor] Unify testing (=updates,prefixes,run configurations,...) 2bcf5793e14577ed3c9f15a77a35179ae544fff4.
2020-04-09 18:07:36 +08:00
; ret = [0, 10)
[Attributor] Unify testing (=updates,prefixes,run configurations,...) When the Attributor was created the test update scripts were not well suited to deal with the challenges of IR attribute checking. This partially improved. Since then we also added three additional configurations that need testing; in total we now have the following four: { TUNIT, CGSCC } x { old pass manager (OPM), new pass manager (NPM) } Finally, the number of developers and tests grew rapidly (partially due to the addition of ArgumentPromotion and IPConstantProp tests), which resulted in tests only being run in some configurations, different prefixes being used, and different "styles" of checks being used. Due to the above reasons I believed we needed to take another look at the test update scripts. While we started to use them, via UTC_ARGS: --enable/disable, the other problems remained. To improve the testing situation for *all* configurations, to simplify future updates to the test, and to help identify subtle effects of future changes, we now use the test update scripts for (almost) all Attributor tests. An exhaustive prefix list minimizes the number of check lines and makes it easy to identify and compare configurations. Tests have been adjusted in the process but we tried to keep their intend unchanged. Reviewed By: sstefan1 Differential Revision: https://reviews.llvm.org/D76588
2020-04-09 08:04:57 +08:00
; IS__TUNIT____-LABEL: define {{[^@]+}}@test0-icmp-check
; IS__TUNIT____-SAME: (i32* nocapture nofree readonly align 4 [[P:%.*]])
; IS__TUNIT____-NEXT: [[RET:%.*]] = tail call i32 @test0(i32* nocapture nofree readonly align 4 [[P]]) #4, !range !0
; IS__TUNIT____-NEXT: [[CMP_EQ_2:%.*]] = icmp eq i32 [[RET]], 9
; IS__TUNIT____-NEXT: [[CMP_EQ_3:%.*]] = icmp eq i32 [[RET]], 8
; IS__TUNIT____-NEXT: [[CMP_EQ_4:%.*]] = icmp eq i32 [[RET]], 1
; IS__TUNIT____-NEXT: [[CMP_EQ_5:%.*]] = icmp eq i32 [[RET]], 0
; IS__TUNIT____-NEXT: tail call void @use3(i1 false, i1 [[CMP_EQ_2]], i1 [[CMP_EQ_3]])
; IS__TUNIT____-NEXT: tail call void @use3(i1 [[CMP_EQ_4]], i1 [[CMP_EQ_5]], i1 false)
; IS__TUNIT____-NEXT: [[CMP_NE_2:%.*]] = icmp ne i32 [[RET]], 9
; IS__TUNIT____-NEXT: [[CMP_NE_3:%.*]] = icmp ne i32 [[RET]], 8
; IS__TUNIT____-NEXT: [[CMP_NE_4:%.*]] = icmp ne i32 [[RET]], 1
; IS__TUNIT____-NEXT: [[CMP_NE_5:%.*]] = icmp ne i32 [[RET]], 0
; IS__TUNIT____-NEXT: tail call void @use3(i1 true, i1 [[CMP_NE_2]], i1 [[CMP_NE_3]])
; IS__TUNIT____-NEXT: tail call void @use3(i1 [[CMP_NE_4]], i1 [[CMP_NE_5]], i1 true)
; IS__TUNIT____-NEXT: [[CMP_UGT_3:%.*]] = icmp ugt i32 [[RET]], 8
; IS__TUNIT____-NEXT: [[CMP_UGT_4:%.*]] = icmp ugt i32 [[RET]], 1
; IS__TUNIT____-NEXT: [[CMP_UGT_5:%.*]] = icmp ugt i32 [[RET]], 0
; IS__TUNIT____-NEXT: tail call void @use3(i1 false, i1 false, i1 [[CMP_UGT_3]])
; IS__TUNIT____-NEXT: tail call void @use3(i1 [[CMP_UGT_4]], i1 [[CMP_UGT_5]], i1 false)
; IS__TUNIT____-NEXT: [[CMP_UGE_2:%.*]] = icmp uge i32 [[RET]], 9
; IS__TUNIT____-NEXT: [[CMP_UGE_3:%.*]] = icmp uge i32 [[RET]], 8
; IS__TUNIT____-NEXT: [[CMP_UGE_4:%.*]] = icmp uge i32 [[RET]], 1
; IS__TUNIT____-NEXT: tail call void @use3(i1 false, i1 [[CMP_UGE_2]], i1 [[CMP_UGE_3]])
; IS__TUNIT____-NEXT: tail call void @use3(i1 [[CMP_UGE_4]], i1 true, i1 false)
; IS__TUNIT____-NEXT: [[CMP_SGT_3:%.*]] = icmp sgt i32 [[RET]], 8
; IS__TUNIT____-NEXT: [[CMP_SGT_4:%.*]] = icmp sgt i32 [[RET]], 1
; IS__TUNIT____-NEXT: [[CMP_SGT_5:%.*]] = icmp sgt i32 [[RET]], 0
; IS__TUNIT____-NEXT: tail call void @use3(i1 false, i1 false, i1 [[CMP_SGT_3]])
; IS__TUNIT____-NEXT: tail call void @use3(i1 [[CMP_SGT_4]], i1 [[CMP_SGT_5]], i1 true)
; IS__TUNIT____-NEXT: [[CMP_GTE_2:%.*]] = icmp sge i32 [[RET]], 9
; IS__TUNIT____-NEXT: [[CMP_GTE_3:%.*]] = icmp sge i32 [[RET]], 8
; IS__TUNIT____-NEXT: [[CMP_GTE_4:%.*]] = icmp sge i32 [[RET]], 1
; IS__TUNIT____-NEXT: tail call void @use3(i1 false, i1 [[CMP_GTE_2]], i1 [[CMP_GTE_3]])
; IS__TUNIT____-NEXT: tail call void @use3(i1 [[CMP_GTE_4]], i1 true, i1 true)
; IS__TUNIT____-NEXT: [[CMP_SLT_2:%.*]] = icmp slt i32 [[RET]], 9
; IS__TUNIT____-NEXT: [[CMP_SLT_3:%.*]] = icmp slt i32 [[RET]], 8
; IS__TUNIT____-NEXT: [[CMP_SLT_4:%.*]] = icmp slt i32 [[RET]], 1
; IS__TUNIT____-NEXT: tail call void @use3(i1 true, i1 [[CMP_SLT_2]], i1 [[CMP_SLT_3]])
; IS__TUNIT____-NEXT: tail call void @use3(i1 [[CMP_SLT_4]], i1 false, i1 false)
; IS__TUNIT____-NEXT: [[CMP_LTE_3:%.*]] = icmp sle i32 [[RET]], 8
; IS__TUNIT____-NEXT: [[CMP_LTE_4:%.*]] = icmp sle i32 [[RET]], 1
; IS__TUNIT____-NEXT: [[CMP_LTE_5:%.*]] = icmp sle i32 [[RET]], 0
; IS__TUNIT____-NEXT: tail call void @use3(i1 true, i1 true, i1 [[CMP_LTE_3]])
; IS__TUNIT____-NEXT: tail call void @use3(i1 [[CMP_LTE_4]], i1 [[CMP_LTE_5]], i1 false)
; IS__TUNIT____-NEXT: ret void
;
; IS__CGSCC____-LABEL: define {{[^@]+}}@test0-icmp-check
; IS__CGSCC____-SAME: (i32* nocapture nofree nonnull readonly align 4 dereferenceable(4) [[P:%.*]])
; IS__CGSCC____-NEXT: [[RET:%.*]] = tail call i32 @test0(i32* nocapture nofree nonnull readonly align 4 dereferenceable(4) [[P]])
; IS__CGSCC____-NEXT: [[CMP_EQ_1:%.*]] = icmp eq i32 [[RET]], 10
; IS__CGSCC____-NEXT: [[CMP_EQ_2:%.*]] = icmp eq i32 [[RET]], 9
; IS__CGSCC____-NEXT: [[CMP_EQ_3:%.*]] = icmp eq i32 [[RET]], 8
; IS__CGSCC____-NEXT: [[CMP_EQ_4:%.*]] = icmp eq i32 [[RET]], 1
; IS__CGSCC____-NEXT: [[CMP_EQ_5:%.*]] = icmp eq i32 [[RET]], 0
; IS__CGSCC____-NEXT: [[CMP_EQ_6:%.*]] = icmp eq i32 [[RET]], -1
; IS__CGSCC____-NEXT: tail call void @use3(i1 [[CMP_EQ_1]], i1 [[CMP_EQ_2]], i1 [[CMP_EQ_3]])
; IS__CGSCC____-NEXT: tail call void @use3(i1 [[CMP_EQ_4]], i1 [[CMP_EQ_5]], i1 [[CMP_EQ_6]])
; IS__CGSCC____-NEXT: [[CMP_NE_1:%.*]] = icmp ne i32 [[RET]], 10
; IS__CGSCC____-NEXT: [[CMP_NE_2:%.*]] = icmp ne i32 [[RET]], 9
; IS__CGSCC____-NEXT: [[CMP_NE_3:%.*]] = icmp ne i32 [[RET]], 8
; IS__CGSCC____-NEXT: [[CMP_NE_4:%.*]] = icmp ne i32 [[RET]], 1
; IS__CGSCC____-NEXT: [[CMP_NE_5:%.*]] = icmp ne i32 [[RET]], 0
; IS__CGSCC____-NEXT: [[CMP_NE_6:%.*]] = icmp ne i32 [[RET]], -1
; IS__CGSCC____-NEXT: tail call void @use3(i1 [[CMP_NE_1]], i1 [[CMP_NE_2]], i1 [[CMP_NE_3]])
; IS__CGSCC____-NEXT: tail call void @use3(i1 [[CMP_NE_4]], i1 [[CMP_NE_5]], i1 [[CMP_NE_6]])
; IS__CGSCC____-NEXT: [[CMP_UGT_1:%.*]] = icmp ugt i32 [[RET]], 10
; IS__CGSCC____-NEXT: [[CMP_UGT_2:%.*]] = icmp ugt i32 [[RET]], 9
; IS__CGSCC____-NEXT: [[CMP_UGT_3:%.*]] = icmp ugt i32 [[RET]], 8
; IS__CGSCC____-NEXT: [[CMP_UGT_4:%.*]] = icmp ugt i32 [[RET]], 1
; IS__CGSCC____-NEXT: [[CMP_UGT_5:%.*]] = icmp ugt i32 [[RET]], 0
; IS__CGSCC____-NEXT: tail call void @use3(i1 [[CMP_UGT_1]], i1 [[CMP_UGT_2]], i1 [[CMP_UGT_3]])
; IS__CGSCC____-NEXT: tail call void @use3(i1 [[CMP_UGT_4]], i1 [[CMP_UGT_5]], i1 false)
; IS__CGSCC____-NEXT: [[CMP_UGE_1:%.*]] = icmp uge i32 [[RET]], 10
; IS__CGSCC____-NEXT: [[CMP_UGE_2:%.*]] = icmp uge i32 [[RET]], 9
; IS__CGSCC____-NEXT: [[CMP_UGE_3:%.*]] = icmp uge i32 [[RET]], 8
; IS__CGSCC____-NEXT: [[CMP_UGE_4:%.*]] = icmp uge i32 [[RET]], 1
; IS__CGSCC____-NEXT: [[CMP_UGE_6:%.*]] = icmp uge i32 [[RET]], -1
; IS__CGSCC____-NEXT: tail call void @use3(i1 [[CMP_UGE_1]], i1 [[CMP_UGE_2]], i1 [[CMP_UGE_3]])
; IS__CGSCC____-NEXT: tail call void @use3(i1 [[CMP_UGE_4]], i1 true, i1 [[CMP_UGE_6]])
; IS__CGSCC____-NEXT: [[CMP_SGT_1:%.*]] = icmp sgt i32 [[RET]], 10
; IS__CGSCC____-NEXT: [[CMP_SGT_2:%.*]] = icmp sgt i32 [[RET]], 9
; IS__CGSCC____-NEXT: [[CMP_SGT_3:%.*]] = icmp sgt i32 [[RET]], 8
; IS__CGSCC____-NEXT: [[CMP_SGT_4:%.*]] = icmp sgt i32 [[RET]], 1
; IS__CGSCC____-NEXT: [[CMP_SGT_5:%.*]] = icmp sgt i32 [[RET]], 0
; IS__CGSCC____-NEXT: [[CMP_SGT_6:%.*]] = icmp sgt i32 [[RET]], -1
; IS__CGSCC____-NEXT: tail call void @use3(i1 [[CMP_SGT_1]], i1 [[CMP_SGT_2]], i1 [[CMP_SGT_3]])
; IS__CGSCC____-NEXT: tail call void @use3(i1 [[CMP_SGT_4]], i1 [[CMP_SGT_5]], i1 [[CMP_SGT_6]])
; IS__CGSCC____-NEXT: [[CMP_GTE_1:%.*]] = icmp sge i32 [[RET]], 10
; IS__CGSCC____-NEXT: [[CMP_GTE_2:%.*]] = icmp sge i32 [[RET]], 9
; IS__CGSCC____-NEXT: [[CMP_GTE_3:%.*]] = icmp sge i32 [[RET]], 8
; IS__CGSCC____-NEXT: [[CMP_GTE_4:%.*]] = icmp sge i32 [[RET]], 1
; IS__CGSCC____-NEXT: [[CMP_GTE_5:%.*]] = icmp sge i32 [[RET]], 0
; IS__CGSCC____-NEXT: [[CMP_GTE_6:%.*]] = icmp sge i32 [[RET]], -1
; IS__CGSCC____-NEXT: tail call void @use3(i1 [[CMP_GTE_1]], i1 [[CMP_GTE_2]], i1 [[CMP_GTE_3]])
; IS__CGSCC____-NEXT: tail call void @use3(i1 [[CMP_GTE_4]], i1 [[CMP_GTE_5]], i1 [[CMP_GTE_6]])
; IS__CGSCC____-NEXT: [[CMP_SLT_1:%.*]] = icmp slt i32 [[RET]], 10
; IS__CGSCC____-NEXT: [[CMP_SLT_2:%.*]] = icmp slt i32 [[RET]], 9
; IS__CGSCC____-NEXT: [[CMP_SLT_3:%.*]] = icmp slt i32 [[RET]], 8
; IS__CGSCC____-NEXT: [[CMP_SLT_4:%.*]] = icmp slt i32 [[RET]], 1
; IS__CGSCC____-NEXT: [[CMP_SLT_5:%.*]] = icmp slt i32 [[RET]], 0
; IS__CGSCC____-NEXT: [[CMP_SLT_6:%.*]] = icmp slt i32 [[RET]], -1
; IS__CGSCC____-NEXT: tail call void @use3(i1 [[CMP_SLT_1]], i1 [[CMP_SLT_2]], i1 [[CMP_SLT_3]])
; IS__CGSCC____-NEXT: tail call void @use3(i1 [[CMP_SLT_4]], i1 [[CMP_SLT_5]], i1 [[CMP_SLT_6]])
; IS__CGSCC____-NEXT: [[CMP_LTE_1:%.*]] = icmp sle i32 [[RET]], 10
; IS__CGSCC____-NEXT: [[CMP_LTE_2:%.*]] = icmp sle i32 [[RET]], 9
; IS__CGSCC____-NEXT: [[CMP_LTE_3:%.*]] = icmp sle i32 [[RET]], 8
; IS__CGSCC____-NEXT: [[CMP_LTE_4:%.*]] = icmp sle i32 [[RET]], 1
; IS__CGSCC____-NEXT: [[CMP_LTE_5:%.*]] = icmp sle i32 [[RET]], 0
; IS__CGSCC____-NEXT: [[CMP_LTE_6:%.*]] = icmp sle i32 [[RET]], -1
; IS__CGSCC____-NEXT: tail call void @use3(i1 [[CMP_LTE_1]], i1 [[CMP_LTE_2]], i1 [[CMP_LTE_3]])
; IS__CGSCC____-NEXT: tail call void @use3(i1 [[CMP_LTE_4]], i1 [[CMP_LTE_5]], i1 [[CMP_LTE_6]])
; IS__CGSCC____-NEXT: ret void
;
[Attributor] AAValueConstantRange: Value range analysis using constant range Summary: This patch introduces `AAValueConstantRange`, which answers a possible range for integer value in a specific program point. One of the motivations is propagating existing `range` metadata. (I think we need to change the situation that `range` metadata cannot be put to Argument). The state is a tuple of `ConstantRange` and it is initialized to (known, assumed) = ([-∞, +∞], empty). Currently, AAValueConstantRange is created in `getAssumedConstant` method when `AAValueSimplify` returns `nullptr`(worst state). Supported - BinaryOperator(add, sub, ...) - CmpInst(icmp eq, ...) - !range metadata `AAValueConstantRange` is not intended to extend to polyhedral range value analysis. Reviewers: jdoerfert, sstefan1 Reviewed By: jdoerfert Subscribers: phosek, davezarzycki, baziotis, hiraditya, javed.absar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71620
2020-01-15 14:25:52 +08:00
%ret = tail call i32 @test0(i32 *%p)
; ret = [0, 10), eq
%cmp-eq-1 = icmp eq i32 %ret, 10
%cmp-eq-2 = icmp eq i32 %ret, 9
%cmp-eq-3 = icmp eq i32 %ret, 8
%cmp-eq-4 = icmp eq i32 %ret, 1
%cmp-eq-5 = icmp eq i32 %ret, 0
%cmp-eq-6 = icmp eq i32 %ret, -1
tail call void @use3(i1 %cmp-eq-1, i1 %cmp-eq-2, i1 %cmp-eq-3)
tail call void @use3(i1 %cmp-eq-4, i1 %cmp-eq-5, i1 %cmp-eq-6)
; ret = [0, 10), ne
%cmp-ne-1 = icmp ne i32 %ret, 10
%cmp-ne-2 = icmp ne i32 %ret, 9
%cmp-ne-3 = icmp ne i32 %ret, 8
%cmp-ne-4 = icmp ne i32 %ret, 1
%cmp-ne-5 = icmp ne i32 %ret, 0
%cmp-ne-6 = icmp ne i32 %ret, -1
tail call void @use3(i1 %cmp-ne-1, i1 %cmp-ne-2, i1 %cmp-ne-3)
tail call void @use3(i1 %cmp-ne-4, i1 %cmp-ne-5, i1 %cmp-ne-6)
; ret = [0, 10), ugt
%cmp-ugt-1 = icmp ugt i32 %ret, 10
%cmp-ugt-2 = icmp ugt i32 %ret, 9
%cmp-ugt-3 = icmp ugt i32 %ret, 8
%cmp-ugt-4 = icmp ugt i32 %ret, 1
%cmp-ugt-5 = icmp ugt i32 %ret, 0
%cmp-ugt-6 = icmp ugt i32 %ret, -1
tail call void @use3(i1 %cmp-ugt-1, i1 %cmp-ugt-2, i1 %cmp-ugt-3)
tail call void @use3(i1 %cmp-ugt-4, i1 %cmp-ugt-5, i1 %cmp-ugt-6)
; ret = [0, 10), uge
%cmp-uge-1 = icmp uge i32 %ret, 10
%cmp-uge-2 = icmp uge i32 %ret, 9
%cmp-uge-3 = icmp uge i32 %ret, 8
%cmp-uge-4 = icmp uge i32 %ret, 1
%cmp-uge-5 = icmp uge i32 %ret, 0
%cmp-uge-6 = icmp uge i32 %ret, -1
tail call void @use3(i1 %cmp-uge-1, i1 %cmp-uge-2, i1 %cmp-uge-3)
tail call void @use3(i1 %cmp-uge-4, i1 %cmp-uge-5, i1 %cmp-uge-6)
; ret = [0, 10), sgt
%cmp-sgt-1 = icmp sgt i32 %ret, 10
%cmp-sgt-2 = icmp sgt i32 %ret, 9
%cmp-sgt-3 = icmp sgt i32 %ret, 8
%cmp-sgt-4 = icmp sgt i32 %ret, 1
%cmp-sgt-5 = icmp sgt i32 %ret, 0
%cmp-sgt-6 = icmp sgt i32 %ret, -1
tail call void @use3(i1 %cmp-sgt-1, i1 %cmp-sgt-2, i1 %cmp-sgt-3)
tail call void @use3(i1 %cmp-sgt-4, i1 %cmp-sgt-5, i1 %cmp-sgt-6)
; ret = [0, 10), sge
%cmp-gte-1 = icmp sge i32 %ret, 10
%cmp-gte-2 = icmp sge i32 %ret, 9
%cmp-gte-3 = icmp sge i32 %ret, 8
%cmp-gte-4 = icmp sge i32 %ret, 1
%cmp-gte-5 = icmp sge i32 %ret, 0
%cmp-gte-6 = icmp sge i32 %ret, -1
tail call void @use3(i1 %cmp-gte-1, i1 %cmp-gte-2, i1 %cmp-gte-3)
tail call void @use3(i1 %cmp-gte-4, i1 %cmp-gte-5, i1 %cmp-gte-6)
; ret = [0, 10), slt
%cmp-slt-1 = icmp slt i32 %ret, 10
%cmp-slt-2 = icmp slt i32 %ret, 9
%cmp-slt-3 = icmp slt i32 %ret, 8
%cmp-slt-4 = icmp slt i32 %ret, 1
%cmp-slt-5 = icmp slt i32 %ret, 0
%cmp-slt-6 = icmp slt i32 %ret, -1
tail call void @use3(i1 %cmp-slt-1, i1 %cmp-slt-2, i1 %cmp-slt-3)
tail call void @use3(i1 %cmp-slt-4, i1 %cmp-slt-5, i1 %cmp-slt-6)
; ret = [0, 10), sle
%cmp-lte-1 = icmp sle i32 %ret, 10
%cmp-lte-2 = icmp sle i32 %ret, 9
%cmp-lte-3 = icmp sle i32 %ret, 8
%cmp-lte-4 = icmp sle i32 %ret, 1
%cmp-lte-5 = icmp sle i32 %ret, 0
%cmp-lte-6 = icmp sle i32 %ret, -1
tail call void @use3(i1 %cmp-lte-1, i1 %cmp-lte-2, i1 %cmp-lte-3)
tail call void @use3(i1 %cmp-lte-4, i1 %cmp-lte-5, i1 %cmp-lte-6)
ret void
}
define i32 @test1(i32* %p) {
; CHECK-LABEL: define {{[^@]+}}@test1
[Attributor] Derive better alignment for accessed pointers Use DL & ABI information for better alignment deduction, e.g., if a type is accessed and the ABI specifies an alignment requirement for such an access we can use it. This is based on a patch by @lebedev.ri and inspired by getBaseAlign in Loads.cpp. Depends on D76673. Reviewed By: lebedev.ri Differential Revision: https://reviews.llvm.org/D76674
2020-04-02 10:46:03 +08:00
; CHECK-SAME: (i32* nocapture nofree nonnull readonly align 4 dereferenceable(4) [[P:%.*]])
; CHECK-NEXT: [[LOAD_10_100:%.*]] = load i32, i32* [[P]], align 4, !range !1
[Attributor] AAValueConstantRange: Value range analysis using constant range Summary: This patch introduces `AAValueConstantRange`, which answers a possible range for integer value in a specific program point. One of the motivations is propagating existing `range` metadata. (I think we need to change the situation that `range` metadata cannot be put to Argument). The state is a tuple of `ConstantRange` and it is initialized to (known, assumed) = ([-∞, +∞], empty). Currently, AAValueConstantRange is created in `getAssumedConstant` method when `AAValueSimplify` returns `nullptr`(worst state). Supported - BinaryOperator(add, sub, ...) - CmpInst(icmp eq, ...) - !range metadata `AAValueConstantRange` is not intended to extend to polyhedral range value analysis. Reviewers: jdoerfert, sstefan1 Reviewed By: jdoerfert Subscribers: phosek, davezarzycki, baziotis, hiraditya, javed.absar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71620
2020-01-15 14:25:52 +08:00
; CHECK-NEXT: [[ADD_10_THEN_20_110:%.*]] = add i32 [[LOAD_10_100]], 10
; CHECK-NEXT: [[MUL_10_THEN_200_1091:%.*]] = mul i32 [[ADD_10_THEN_20_110]], 10
; CHECK-NEXT: ret i32 [[MUL_10_THEN_200_1091]]
;
%load-10-100 = load i32, i32* %p, !range !1
%add-10-then-20-110 = add i32 %load-10-100, 10
%mul-10-then-200-1091 = mul i32 %add-10-then-20-110, 10
ret i32 %mul-10-then-200-1091
}
define i1 @test1-check(i32* %p) {
[Attributor][FIX] Make check lines explicit There is a bug in `update_test_checks.py` that combines check lines it should not. For now we unbreak the bots by making all possibilities explicit.
2020-02-10 15:31:20 +08:00
;
[Attributor] Unify testing (=updates,prefixes,run configurations,...) When the Attributor was created the test update scripts were not well suited to deal with the challenges of IR attribute checking. This partially improved. Since then we also added three additional configurations that need testing; in total we now have the following four: { TUNIT, CGSCC } x { old pass manager (OPM), new pass manager (NPM) } Finally, the number of developers and tests grew rapidly (partially due to the addition of ArgumentPromotion and IPConstantProp tests), which resulted in tests only being run in some configurations, different prefixes being used, and different "styles" of checks being used. Due to the above reasons I believed we needed to take another look at the test update scripts. While we started to use them, via UTC_ARGS: --enable/disable, the other problems remained. To improve the testing situation for *all* configurations, to simplify future updates to the test, and to help identify subtle effects of future changes, we now use the test update scripts for (almost) all Attributor tests. An exhaustive prefix list minimizes the number of check lines and makes it easy to identify and compare configurations. Tests have been adjusted in the process but we tried to keep their intend unchanged. Reviewed By: sstefan1 Differential Revision: https://reviews.llvm.org/D76588
2020-04-09 08:04:57 +08:00
; IS__TUNIT____-LABEL: define {{[^@]+}}@test1-check
; IS__TUNIT____-SAME: (i32* nocapture nofree readonly align 4 [[P:%.*]])
; IS__TUNIT____-NEXT: [[RES:%.*]] = tail call i32 @test1(i32* nocapture nofree readonly align 4 [[P]]) #4, !range !2
; IS__TUNIT____-NEXT: [[CMP:%.*]] = icmp eq i32 [[RES]], 500
; IS__TUNIT____-NEXT: ret i1 [[CMP]]
[Attributor][FIX] Make check lines explicit There is a bug in `update_test_checks.py` that combines check lines it should not. For now we unbreak the bots by making all possibilities explicit.
2020-02-10 15:31:20 +08:00
;
[Attributor] Unify testing (=updates,prefixes,run configurations,...) When the Attributor was created the test update scripts were not well suited to deal with the challenges of IR attribute checking. This partially improved. Since then we also added three additional configurations that need testing; in total we now have the following four: { TUNIT, CGSCC } x { old pass manager (OPM), new pass manager (NPM) } Finally, the number of developers and tests grew rapidly (partially due to the addition of ArgumentPromotion and IPConstantProp tests), which resulted in tests only being run in some configurations, different prefixes being used, and different "styles" of checks being used. Due to the above reasons I believed we needed to take another look at the test update scripts. While we started to use them, via UTC_ARGS: --enable/disable, the other problems remained. To improve the testing situation for *all* configurations, to simplify future updates to the test, and to help identify subtle effects of future changes, we now use the test update scripts for (almost) all Attributor tests. An exhaustive prefix list minimizes the number of check lines and makes it easy to identify and compare configurations. Tests have been adjusted in the process but we tried to keep their intend unchanged. Reviewed By: sstefan1 Differential Revision: https://reviews.llvm.org/D76588
2020-04-09 08:04:57 +08:00
; IS__CGSCC____-LABEL: define {{[^@]+}}@test1-check
; IS__CGSCC____-SAME: (i32* nocapture nofree nonnull readonly align 4 dereferenceable(4) [[P:%.*]])
; IS__CGSCC____-NEXT: [[RES:%.*]] = tail call i32 @test1(i32* nocapture nofree nonnull readonly align 4 dereferenceable(4) [[P]])
; IS__CGSCC____-NEXT: [[CMP:%.*]] = icmp eq i32 [[RES]], 500
; IS__CGSCC____-NEXT: ret i1 [[CMP]]
[Attributor][FIX] Make check lines explicit There is a bug in `update_test_checks.py` that combines check lines it should not. For now we unbreak the bots by making all possibilities explicit.
2020-02-10 15:31:20 +08:00
;
[Attributor] AAValueConstantRange: Value range analysis using constant range Summary: This patch introduces `AAValueConstantRange`, which answers a possible range for integer value in a specific program point. One of the motivations is propagating existing `range` metadata. (I think we need to change the situation that `range` metadata cannot be put to Argument). The state is a tuple of `ConstantRange` and it is initialized to (known, assumed) = ([-∞, +∞], empty). Currently, AAValueConstantRange is created in `getAssumedConstant` method when `AAValueSimplify` returns `nullptr`(worst state). Supported - BinaryOperator(add, sub, ...) - CmpInst(icmp eq, ...) - !range metadata `AAValueConstantRange` is not intended to extend to polyhedral range value analysis. Reviewers: jdoerfert, sstefan1 Reviewed By: jdoerfert Subscribers: phosek, davezarzycki, baziotis, hiraditya, javed.absar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71620
2020-01-15 14:25:52 +08:00
%res = tail call i32 @test1(i32* %p)
%cmp = icmp eq i32 %res, 500
ret i1 %cmp
}
; TEST2
; int test2(int *p) { return *p == 0 ? 4 : 3; }
; int test2_check(int *p) {
; int call = test2(p);
; if (call == 5) {
; // dead block
; return 2;
; } else {
; return 3;
; }
; }
define i32 @test2(i32* %p) {
; CHECK-LABEL: define {{[^@]+}}@test2
; CHECK-SAME: (i32* nocapture nofree nonnull readonly align 4 dereferenceable(4) [[P:%.*]])
; CHECK-NEXT: entry:
; CHECK-NEXT: [[TMP0:%.*]] = load i32, i32* [[P]], align 4
; CHECK-NEXT: [[TOBOOL:%.*]] = icmp eq i32 [[TMP0]], 0
; CHECK-NEXT: [[COND:%.*]] = select i1 [[TOBOOL]], i32 4, i32 3
; CHECK-NEXT: ret i32 [[COND]]
;
entry:
%0 = load i32, i32* %p, align 4
%tobool = icmp eq i32 %0, 0
%cond = select i1 %tobool, i32 4, i32 3
ret i32 %cond
}
define i32 @test2_check(i32* %p) {
[Attributor] Unify testing (=updates,prefixes,run configurations,...) When the Attributor was created the test update scripts were not well suited to deal with the challenges of IR attribute checking. This partially improved. Since then we also added three additional configurations that need testing; in total we now have the following four: { TUNIT, CGSCC } x { old pass manager (OPM), new pass manager (NPM) } Finally, the number of developers and tests grew rapidly (partially due to the addition of ArgumentPromotion and IPConstantProp tests), which resulted in tests only being run in some configurations, different prefixes being used, and different "styles" of checks being used. Due to the above reasons I believed we needed to take another look at the test update scripts. While we started to use them, via UTC_ARGS: --enable/disable, the other problems remained. To improve the testing situation for *all* configurations, to simplify future updates to the test, and to help identify subtle effects of future changes, we now use the test update scripts for (almost) all Attributor tests. An exhaustive prefix list minimizes the number of check lines and makes it easy to identify and compare configurations. Tests have been adjusted in the process but we tried to keep their intend unchanged. Reviewed By: sstefan1 Differential Revision: https://reviews.llvm.org/D76588
2020-04-09 08:04:57 +08:00
; IS__TUNIT____-LABEL: define {{[^@]+}}@test2_check
; IS__TUNIT____-SAME: (i32* nocapture nofree readnone align 4 [[P:%.*]])
; IS__TUNIT____-NEXT: entry:
; IS__TUNIT____-NEXT: br label [[IF_THEN:%.*]]
; IS__TUNIT____: if.then:
; IS__TUNIT____-NEXT: br label [[RETURN:%.*]]
; IS__TUNIT____: if.end:
; IS__TUNIT____-NEXT: unreachable
; IS__TUNIT____: return:
; IS__TUNIT____-NEXT: ret i32 2
;
; IS__CGSCC____-LABEL: define {{[^@]+}}@test2_check
; IS__CGSCC____-SAME: (i32* nocapture nofree nonnull readonly align 4 dereferenceable(4) [[P:%.*]])
; IS__CGSCC____-NEXT: entry:
; IS__CGSCC____-NEXT: [[CALL:%.*]] = tail call i32 @test2(i32* nocapture nofree nonnull readonly align 4 dereferenceable(4) [[P]])
; IS__CGSCC____-NEXT: [[CMP:%.*]] = icmp slt i32 [[CALL]], 5
; IS__CGSCC____-NEXT: br i1 [[CMP]], label [[IF_THEN:%.*]], label [[IF_END:%.*]]
; IS__CGSCC____: if.then:
; IS__CGSCC____-NEXT: br label [[RETURN:%.*]]
; IS__CGSCC____: if.end:
; IS__CGSCC____-NEXT: br label [[RETURN]]
; IS__CGSCC____: return:
; IS__CGSCC____-NEXT: [[RETVAL_0:%.*]] = phi i32 [ 2, [[IF_THEN]] ], [ 3, [[IF_END]] ]
; IS__CGSCC____-NEXT: ret i32 [[RETVAL_0]]
[Attributor][FIX] Make check lines explicit There is a bug in `update_test_checks.py` that combines check lines it should not. For now we unbreak the bots by making all possibilities explicit.
2020-02-10 15:31:20 +08:00
;
[Attributor] AAValueConstantRange: Value range analysis using constant range Summary: This patch introduces `AAValueConstantRange`, which answers a possible range for integer value in a specific program point. One of the motivations is propagating existing `range` metadata. (I think we need to change the situation that `range` metadata cannot be put to Argument). The state is a tuple of `ConstantRange` and it is initialized to (known, assumed) = ([-∞, +∞], empty). Currently, AAValueConstantRange is created in `getAssumedConstant` method when `AAValueSimplify` returns `nullptr`(worst state). Supported - BinaryOperator(add, sub, ...) - CmpInst(icmp eq, ...) - !range metadata `AAValueConstantRange` is not intended to extend to polyhedral range value analysis. Reviewers: jdoerfert, sstefan1 Reviewed By: jdoerfert Subscribers: phosek, davezarzycki, baziotis, hiraditya, javed.absar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71620
2020-01-15 14:25:52 +08:00
entry:
%call = tail call i32 @test2(i32* %p)
%cmp = icmp slt i32 %call, 5
br i1 %cmp, label %if.then, label %if.end
if.then: ; preds = %entry
br label %return
if.end: ; preds = %entry
br label %return
return: ; preds = %if.end, %if.then
%retval.0 = phi i32 [ 2, %if.then ], [ 3, %if.end ]
ret i32 %retval.0
}
; TEST 3 SECV test
; void unkown();
; int r1(unsigned int u){
; int sum = 0;
; for(int i = 0; i<100;i++){
; sum += i;
; }
; // sum = 50 * 49 / 2
; if(sum > 10000){
; // dead block
; return 20;
; }else {
; return 10;
; }
; }
; void f1(int u){
; if(r1(u) > 15){
; // deadblock
; unkown();
; }else {
; return;
; }
; }
declare dso_local void @unkown()
define internal i32 @r1(i32) local_unnamed_addr {
[Attributor] Unify testing (=updates,prefixes,run configurations,...) When the Attributor was created the test update scripts were not well suited to deal with the challenges of IR attribute checking. This partially improved. Since then we also added three additional configurations that need testing; in total we now have the following four: { TUNIT, CGSCC } x { old pass manager (OPM), new pass manager (NPM) } Finally, the number of developers and tests grew rapidly (partially due to the addition of ArgumentPromotion and IPConstantProp tests), which resulted in tests only being run in some configurations, different prefixes being used, and different "styles" of checks being used. Due to the above reasons I believed we needed to take another look at the test update scripts. While we started to use them, via UTC_ARGS: --enable/disable, the other problems remained. To improve the testing situation for *all* configurations, to simplify future updates to the test, and to help identify subtle effects of future changes, we now use the test update scripts for (almost) all Attributor tests. An exhaustive prefix list minimizes the number of check lines and makes it easy to identify and compare configurations. Tests have been adjusted in the process but we tried to keep their intend unchanged. Reviewed By: sstefan1 Differential Revision: https://reviews.llvm.org/D76588
2020-04-09 08:04:57 +08:00
; IS________OPM-LABEL: define {{[^@]+}}@r1() local_unnamed_addr
; IS________OPM-NEXT: br label [[TMP4:%.*]]
; IS________OPM: 1:
; IS________OPM-NEXT: [[TMP2:%.*]] = icmp sgt i32 [[TMP7:%.*]], 10000
; IS________OPM-NEXT: br i1 [[TMP2]], label [[TMP3:%.*]], label [[F:%.*]]
; IS________OPM: 3:
; IS________OPM-NEXT: ret i32 20
; IS________OPM: f:
; IS________OPM-NEXT: ret i32 10
; IS________OPM: 4:
; IS________OPM-NEXT: [[TMP5:%.*]] = phi i32 [ 0, [[TMP0:%.*]] ], [ [[TMP8:%.*]], [[TMP4]] ]
; IS________OPM-NEXT: [[TMP6:%.*]] = phi i32 [ 0, [[TMP0]] ], [ [[TMP7]], [[TMP4]] ]
; IS________OPM-NEXT: [[TMP7]] = add nuw nsw i32 [[TMP5]], [[TMP6]]
; IS________OPM-NEXT: [[TMP8]] = add nuw nsw i32 [[TMP5]], 1
; IS________OPM-NEXT: [[TMP9:%.*]] = icmp eq i32 [[TMP8]], 100
; IS________OPM-NEXT: br i1 [[TMP9]], label [[TMP1:%.*]], label [[TMP4]]
;
; IS__CGSCC_NPM-LABEL: define {{[^@]+}}@r1() local_unnamed_addr
; IS__CGSCC_NPM-NEXT: br label [[TMP3:%.*]]
; IS__CGSCC_NPM: 1:
; IS__CGSCC_NPM-NEXT: br label [[F:%.*]]
; IS__CGSCC_NPM: 2:
; IS__CGSCC_NPM-NEXT: unreachable
; IS__CGSCC_NPM: f:
; IS__CGSCC_NPM-NEXT: ret i32 10
; IS__CGSCC_NPM: 3:
; IS__CGSCC_NPM-NEXT: [[TMP4:%.*]] = phi i32 [ 0, [[TMP0:%.*]] ], [ [[TMP7:%.*]], [[TMP3]] ]
; IS__CGSCC_NPM-NEXT: [[TMP5:%.*]] = phi i32 [ 0, [[TMP0]] ], [ [[TMP6:%.*]], [[TMP3]] ]
; IS__CGSCC_NPM-NEXT: [[TMP6]] = add nuw nsw i32 [[TMP4]], [[TMP5]]
; IS__CGSCC_NPM-NEXT: [[TMP7]] = add nuw nsw i32 [[TMP4]], 1
; IS__CGSCC_NPM-NEXT: [[TMP8:%.*]] = icmp eq i32 [[TMP7]], 100
; IS__CGSCC_NPM-NEXT: br i1 [[TMP8]], label [[TMP1:%.*]], label [[TMP3]]
[Attributor] AAValueConstantRange: Value range analysis using constant range Summary: This patch introduces `AAValueConstantRange`, which answers a possible range for integer value in a specific program point. One of the motivations is propagating existing `range` metadata. (I think we need to change the situation that `range` metadata cannot be put to Argument). The state is a tuple of `ConstantRange` and it is initialized to (known, assumed) = ([-∞, +∞], empty). Currently, AAValueConstantRange is created in `getAssumedConstant` method when `AAValueSimplify` returns `nullptr`(worst state). Supported - BinaryOperator(add, sub, ...) - CmpInst(icmp eq, ...) - !range metadata `AAValueConstantRange` is not intended to extend to polyhedral range value analysis. Reviewers: jdoerfert, sstefan1 Reviewed By: jdoerfert Subscribers: phosek, davezarzycki, baziotis, hiraditya, javed.absar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71620
2020-01-15 14:25:52 +08:00
;
br label %5
2: ; preds = %5
%3 = icmp sgt i32 %8, 10000
br i1 %3, label %4, label %f
4:
ret i32 20
f:
ret i32 10
5: ; preds = %5, %1
%6 = phi i32 [ 0, %1 ], [ %9, %5 ]
%7 = phi i32 [ 0, %1 ], [ %8, %5 ]
%8 = add nuw nsw i32 %6, %7
%9 = add nuw nsw i32 %6, 1
%10 = icmp eq i32 %9, 100
br i1 %10, label %2, label %5
}
define void @f1(i32){
[Attributor] Unify testing (=updates,prefixes,run configurations,...) When the Attributor was created the test update scripts were not well suited to deal with the challenges of IR attribute checking. This partially improved. Since then we also added three additional configurations that need testing; in total we now have the following four: { TUNIT, CGSCC } x { old pass manager (OPM), new pass manager (NPM) } Finally, the number of developers and tests grew rapidly (partially due to the addition of ArgumentPromotion and IPConstantProp tests), which resulted in tests only being run in some configurations, different prefixes being used, and different "styles" of checks being used. Due to the above reasons I believed we needed to take another look at the test update scripts. While we started to use them, via UTC_ARGS: --enable/disable, the other problems remained. To improve the testing situation for *all* configurations, to simplify future updates to the test, and to help identify subtle effects of future changes, we now use the test update scripts for (almost) all Attributor tests. An exhaustive prefix list minimizes the number of check lines and makes it easy to identify and compare configurations. Tests have been adjusted in the process but we tried to keep their intend unchanged. Reviewed By: sstefan1 Differential Revision: https://reviews.llvm.org/D76588
2020-04-09 08:04:57 +08:00
; IS________OPM-LABEL: define {{[^@]+}}@f1
; IS________OPM-SAME: (i32 [[TMP0:%.*]])
; IS________OPM-NEXT: [[TMP2:%.*]] = tail call i32 @r1()
; IS________OPM-NEXT: [[TMP3:%.*]] = icmp sgt i32 [[TMP2]], 15
; IS________OPM-NEXT: br i1 [[TMP3]], label [[TMP4:%.*]], label [[TMP5:%.*]]
; IS________OPM: 4:
; IS________OPM-NEXT: tail call void @unkown()
; IS________OPM-NEXT: br label [[TMP5]]
; IS________OPM: 5:
; IS________OPM-NEXT: ret void
;
[Attributor] Remove dependence edges eagerly If we have a dependence between an abstract attribute A to an abstract attribute B such hat changes in A should trigger an update of B, we do not need to keep the dependence around once the update was triggered. If the dependence is still required the update will reinsert it into the dependence map, if it is not we avoid triggering B in the future. This replaces the "recompute interval" mechanism we used before to prune stale dependences. Number of required iterations is generally down, compile time for the module pass (not really the CGSCC pass) is down quite a bit. There is one test change which looks like an artifact in the undefined behavior AA that needs to be looked at.
2020-04-22 02:57:19 +08:00
; IS__TUNIT_NPM-LABEL: define {{[^@]+}}@f1
; IS__TUNIT_NPM-SAME: (i32 [[TMP0:%.*]])
; IS__TUNIT_NPM-NEXT: br label [[TMP3:%.*]]
; IS__TUNIT_NPM: 2:
; IS__TUNIT_NPM-NEXT: tail call void @unkown()
; IS__TUNIT_NPM-NEXT: br label [[TMP3]]
; IS__TUNIT_NPM: 3:
; IS__TUNIT_NPM-NEXT: ret void
;
; IS__CGSCC_NPM-LABEL: define {{[^@]+}}@f1
; IS__CGSCC_NPM-SAME: (i32 [[TMP0:%.*]])
; IS__CGSCC_NPM-NEXT: br label [[TMP3:%.*]]
; IS__CGSCC_NPM: 2:
; IS__CGSCC_NPM-NEXT: unreachable
; IS__CGSCC_NPM: 3:
; IS__CGSCC_NPM-NEXT: ret void
[Attributor] AAValueConstantRange: Value range analysis using constant range Summary: This patch introduces `AAValueConstantRange`, which answers a possible range for integer value in a specific program point. One of the motivations is propagating existing `range` metadata. (I think we need to change the situation that `range` metadata cannot be put to Argument). The state is a tuple of `ConstantRange` and it is initialized to (known, assumed) = ([-∞, +∞], empty). Currently, AAValueConstantRange is created in `getAssumedConstant` method when `AAValueSimplify` returns `nullptr`(worst state). Supported - BinaryOperator(add, sub, ...) - CmpInst(icmp eq, ...) - !range metadata `AAValueConstantRange` is not intended to extend to polyhedral range value analysis. Reviewers: jdoerfert, sstefan1 Reviewed By: jdoerfert Subscribers: phosek, davezarzycki, baziotis, hiraditya, javed.absar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71620
2020-01-15 14:25:52 +08:00
;
%2 = tail call i32 @r1(i32 %0)
%3 = icmp sgt i32 %2, 15
br i1 %3, label %4, label %5
4: ; preds = %1
tail call void @unkown()
br label %5
5: ; preds = %1, %4
ret void
}
; TEST4 LVI test
; f1
; int test4-f1(int u){
; if(u>=0) {
; return u;
; }else{
; return 0;
; }
; }
define dso_local i32 @test4-f1(i32 %u) {
; CHECK-LABEL: define {{[^@]+}}@test4-f1
; CHECK-SAME: (i32 [[U:%.*]])
; CHECK-NEXT: entry:
; CHECK-NEXT: [[CMP:%.*]] = icmp sgt i32 [[U]], -1
; CHECK-NEXT: br i1 [[CMP]], label [[IF_THEN:%.*]], label [[RETURN:%.*]]
; CHECK: if.then:
; CHECK-NEXT: br label [[RETURN]]
; CHECK: return:
; CHECK-NEXT: [[RETVAL_0:%.*]] = phi i32 [ [[U]], [[IF_THEN]] ], [ 0, [[ENTRY:%.*]] ]
; CHECK-NEXT: ret i32 [[RETVAL_0]]
;
; FIXME: RETVAL_0 >= 0
entry:
%cmp = icmp sgt i32 %u, -1
br i1 %cmp, label %if.then, label %return
if.then: ; preds = %entry
br label %return
return: ; preds = %entry, %if.then
%retval.0 = phi i32 [ %u, %if.then ], [ 0, %entry ]
ret i32 %retval.0
}
define dso_local i32 @test4-g1(i32 %u) {
; CHECK-LABEL: define {{[^@]+}}@test4-g1
; CHECK-SAME: (i32 [[U:%.*]])
; CHECK-NEXT: entry:
; CHECK-NEXT: [[CALL:%.*]] = tail call i32 @test4-f1(i32 [[U]])
; CHECK-NEXT: ret i32 [[CALL]]
;
; FIXME: %call should have range [0, inf]
entry:
%call = tail call i32 @test4-f1(i32 %u)
ret i32 %call
}
; f2
; int test4-f1(int u){
; if(u>-1) {
; return u+1;
; }else{
; return 1;
; }
; }
define dso_local i32 @test4-f2(i32 %u) {
; CHECK-LABEL: define {{[^@]+}}@test4-f2
; CHECK-SAME: (i32 [[U:%.*]])
; CHECK-NEXT: entry:
; CHECK-NEXT: [[CMP:%.*]] = icmp sgt i32 [[U]], -1
; CHECK-NEXT: br i1 [[CMP]], label [[IF_THEN:%.*]], label [[IF_ELSE:%.*]]
; CHECK: if.then:
; CHECK-NEXT: [[ADD:%.*]] = add nuw nsw i32 [[U]], 1
; CHECK-NEXT: br label [[RETURN:%.*]]
; CHECK: if.else:
; CHECK-NEXT: br label [[RETURN]]
; CHECK: return:
; CHECK-NEXT: [[RETVAL_0:%.*]] = phi i32 [ [[ADD]], [[IF_THEN]] ], [ 1, [[IF_ELSE]] ]
; CHECK-NEXT: ret i32 [[RETVAL_0]]
;
entry:
%cmp = icmp sgt i32 %u, -1
br i1 %cmp, label %if.then, label %if.else
if.then: ; preds = %entry
%add = add nuw nsw i32 %u, 1
br label %return
if.else: ; preds = %entry
br label %return
return: ; preds = %if.else, %if.then
%retval.0 = phi i32 [ %add, %if.then ], [ 1, %if.else ]
ret i32 %retval.0
}
define dso_local i32 @test4-g2(i32 %u) {
[Attributor] Unify testing (=updates,prefixes,run configurations,...) When the Attributor was created the test update scripts were not well suited to deal with the challenges of IR attribute checking. This partially improved. Since then we also added three additional configurations that need testing; in total we now have the following four: { TUNIT, CGSCC } x { old pass manager (OPM), new pass manager (NPM) } Finally, the number of developers and tests grew rapidly (partially due to the addition of ArgumentPromotion and IPConstantProp tests), which resulted in tests only being run in some configurations, different prefixes being used, and different "styles" of checks being used. Due to the above reasons I believed we needed to take another look at the test update scripts. While we started to use them, via UTC_ARGS: --enable/disable, the other problems remained. To improve the testing situation for *all* configurations, to simplify future updates to the test, and to help identify subtle effects of future changes, we now use the test update scripts for (almost) all Attributor tests. An exhaustive prefix list minimizes the number of check lines and makes it easy to identify and compare configurations. Tests have been adjusted in the process but we tried to keep their intend unchanged. Reviewed By: sstefan1 Differential Revision: https://reviews.llvm.org/D76588
2020-04-09 08:04:57 +08:00
; NOT_TUNIT_NPM-LABEL: define {{[^@]+}}@test4-g2
; NOT_TUNIT_NPM-SAME: (i32 [[U:%.*]])
; NOT_TUNIT_NPM-NEXT: entry:
; NOT_TUNIT_NPM-NEXT: [[CALL:%.*]] = tail call i32 @test4-f2(i32 [[U]])
; NOT_TUNIT_NPM-NEXT: ret i32 [[CALL]]
;
; IS__TUNIT_NPM-LABEL: define {{[^@]+}}@test4-g2
; IS__TUNIT_NPM-SAME: (i32 [[U:%.*]])
; IS__TUNIT_NPM-NEXT: entry:
; IS__TUNIT_NPM-NEXT: [[CALL:%.*]] = tail call i32 @test4-f2(i32 [[U]]) #2, !range !3
; IS__TUNIT_NPM-NEXT: ret i32 [[CALL]]
[Attributor][FIX] Make check lines explicit There is a bug in `update_test_checks.py` that combines check lines it should not. For now we unbreak the bots by making all possibilities explicit.
2020-02-10 15:31:20 +08:00
;
[Attributor] AAValueConstantRange: Value range analysis using constant range Summary: This patch introduces `AAValueConstantRange`, which answers a possible range for integer value in a specific program point. One of the motivations is propagating existing `range` metadata. (I think we need to change the situation that `range` metadata cannot be put to Argument). The state is a tuple of `ConstantRange` and it is initialized to (known, assumed) = ([-∞, +∞], empty). Currently, AAValueConstantRange is created in `getAssumedConstant` method when `AAValueSimplify` returns `nullptr`(worst state). Supported - BinaryOperator(add, sub, ...) - CmpInst(icmp eq, ...) - !range metadata `AAValueConstantRange` is not intended to extend to polyhedral range value analysis. Reviewers: jdoerfert, sstefan1 Reviewed By: jdoerfert Subscribers: phosek, davezarzycki, baziotis, hiraditya, javed.absar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71620
2020-01-15 14:25:52 +08:00
entry:
%call = tail call i32 @test4-f2(i32 %u)
ret i32 %call
}
define dso_local i32 @test-5() {
[Attributor] Unify testing (=updates,prefixes,run configurations,...) When the Attributor was created the test update scripts were not well suited to deal with the challenges of IR attribute checking. This partially improved. Since then we also added three additional configurations that need testing; in total we now have the following four: { TUNIT, CGSCC } x { old pass manager (OPM), new pass manager (NPM) } Finally, the number of developers and tests grew rapidly (partially due to the addition of ArgumentPromotion and IPConstantProp tests), which resulted in tests only being run in some configurations, different prefixes being used, and different "styles" of checks being used. Due to the above reasons I believed we needed to take another look at the test update scripts. While we started to use them, via UTC_ARGS: --enable/disable, the other problems remained. To improve the testing situation for *all* configurations, to simplify future updates to the test, and to help identify subtle effects of future changes, we now use the test update scripts for (almost) all Attributor tests. An exhaustive prefix list minimizes the number of check lines and makes it easy to identify and compare configurations. Tests have been adjusted in the process but we tried to keep their intend unchanged. Reviewed By: sstefan1 Differential Revision: https://reviews.llvm.org/D76588
2020-04-09 08:04:57 +08:00
; IS__TUNIT_OPM-LABEL: define {{[^@]+}}@test-5()
; IS__TUNIT_OPM-NEXT: entry:
; IS__TUNIT_OPM-NEXT: [[CALL:%.*]] = call i32 @rec(i32 0), !range !3
; IS__TUNIT_OPM-NEXT: ret i32 [[CALL]]
[Attributor][FIX] Call right base method in AAValueConstantRangeFloating We now call the base class method as we should.
2020-02-10 09:05:15 +08:00
;
[Attributor] Unify testing (=updates,prefixes,run configurations,...) When the Attributor was created the test update scripts were not well suited to deal with the challenges of IR attribute checking. This partially improved. Since then we also added three additional configurations that need testing; in total we now have the following four: { TUNIT, CGSCC } x { old pass manager (OPM), new pass manager (NPM) } Finally, the number of developers and tests grew rapidly (partially due to the addition of ArgumentPromotion and IPConstantProp tests), which resulted in tests only being run in some configurations, different prefixes being used, and different "styles" of checks being used. Due to the above reasons I believed we needed to take another look at the test update scripts. While we started to use them, via UTC_ARGS: --enable/disable, the other problems remained. To improve the testing situation for *all* configurations, to simplify future updates to the test, and to help identify subtle effects of future changes, we now use the test update scripts for (almost) all Attributor tests. An exhaustive prefix list minimizes the number of check lines and makes it easy to identify and compare configurations. Tests have been adjusted in the process but we tried to keep their intend unchanged. Reviewed By: sstefan1 Differential Revision: https://reviews.llvm.org/D76588
2020-04-09 08:04:57 +08:00
; IS__TUNIT_NPM-LABEL: define {{[^@]+}}@test-5()
; IS__TUNIT_NPM-NEXT: entry:
; IS__TUNIT_NPM-NEXT: [[CALL:%.*]] = call i32 @rec(i32 0), !range !4
; IS__TUNIT_NPM-NEXT: ret i32 [[CALL]]
[Attributor][FIX] Make check lines explicit There is a bug in `update_test_checks.py` that combines check lines it should not. For now we unbreak the bots by making all possibilities explicit.
2020-02-10 15:31:20 +08:00
;
[Attributor] Unify testing (=updates,prefixes,run configurations,...) When the Attributor was created the test update scripts were not well suited to deal with the challenges of IR attribute checking. This partially improved. Since then we also added three additional configurations that need testing; in total we now have the following four: { TUNIT, CGSCC } x { old pass manager (OPM), new pass manager (NPM) } Finally, the number of developers and tests grew rapidly (partially due to the addition of ArgumentPromotion and IPConstantProp tests), which resulted in tests only being run in some configurations, different prefixes being used, and different "styles" of checks being used. Due to the above reasons I believed we needed to take another look at the test update scripts. While we started to use them, via UTC_ARGS: --enable/disable, the other problems remained. To improve the testing situation for *all* configurations, to simplify future updates to the test, and to help identify subtle effects of future changes, we now use the test update scripts for (almost) all Attributor tests. An exhaustive prefix list minimizes the number of check lines and makes it easy to identify and compare configurations. Tests have been adjusted in the process but we tried to keep their intend unchanged. Reviewed By: sstefan1 Differential Revision: https://reviews.llvm.org/D76588
2020-04-09 08:04:57 +08:00
; IS__CGSCC____-LABEL: define {{[^@]+}}@test-5()
; IS__CGSCC____-NEXT: entry:
; IS__CGSCC____-NEXT: [[CALL:%.*]] = call i32 @rec(i32 0)
; IS__CGSCC____-NEXT: ret i32 [[CALL]]
[Attributor][Tests] Run the CGSCC versions on the range.ll test
2020-02-10 09:08:19 +08:00
;
[Attributor] AAValueConstantRange: Value range analysis using constant range Summary: This patch introduces `AAValueConstantRange`, which answers a possible range for integer value in a specific program point. One of the motivations is propagating existing `range` metadata. (I think we need to change the situation that `range` metadata cannot be put to Argument). The state is a tuple of `ConstantRange` and it is initialized to (known, assumed) = ([-∞, +∞], empty). Currently, AAValueConstantRange is created in `getAssumedConstant` method when `AAValueSimplify` returns `nullptr`(worst state). Supported - BinaryOperator(add, sub, ...) - CmpInst(icmp eq, ...) - !range metadata `AAValueConstantRange` is not intended to extend to polyhedral range value analysis. Reviewers: jdoerfert, sstefan1 Reviewed By: jdoerfert Subscribers: phosek, davezarzycki, baziotis, hiraditya, javed.absar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71620
2020-01-15 14:25:52 +08:00
entry:
%call = call i32 @rec(i32 0)
ret i32 %call
}
define internal i32 @rec(i32 %depth) {
; CHECK-LABEL: define {{[^@]+}}@rec
; CHECK-SAME: (i32 [[DEPTH:%.*]])
; CHECK-NEXT: entry:
; CHECK-NEXT: [[CALL:%.*]] = call i32 @foo(i32 [[DEPTH]])
; CHECK-NEXT: [[TOBOOL:%.*]] = icmp ne i32 [[CALL]], 0
; CHECK-NEXT: br i1 [[TOBOOL]], label [[IF_THEN:%.*]], label [[IF_END:%.*]]
; CHECK: if.then:
; CHECK-NEXT: br label [[RETURN:%.*]]
; CHECK: if.end:
; CHECK-NEXT: [[CMP:%.*]] = icmp slt i32 [[DEPTH]], 10
; CHECK-NEXT: br i1 [[CMP]], label [[IF_THEN1:%.*]], label [[IF_END3:%.*]]
; CHECK: if.then1:
; CHECK-NEXT: [[ADD:%.*]] = add nsw i32 [[DEPTH]], 1
; CHECK-NEXT: [[CALL2:%.*]] = call i32 @rec(i32 [[ADD]])
; CHECK-NEXT: br label [[IF_END3]]
; CHECK: if.end3:
; CHECK-NEXT: br label [[RETURN]]
; CHECK: return:
; CHECK-NEXT: [[RETVAL_0:%.*]] = phi i32 [ 0, [[IF_THEN]] ], [ 1, [[IF_END3]] ]
; CHECK-NEXT: ret i32 [[RETVAL_0]]
;
entry:
%call = call i32 @foo(i32 %depth)
%tobool = icmp ne i32 %call, 0
br i1 %tobool, label %if.then, label %if.end
if.then: ; preds = %entry
br label %return
if.end: ; preds = %entry
%cmp = icmp slt i32 %depth, 10
br i1 %cmp, label %if.then1, label %if.end3
if.then1: ; preds = %if.end
%add = add nsw i32 %depth, 1
%call2 = call i32 @rec(i32 %add)
br label %if.end3
if.end3: ; preds = %if.then1, %if.end
br label %return
return: ; preds = %if.end3, %if.then
%retval.0 = phi i32 [ 0, %if.then ], [ 1, %if.end3 ]
ret i32 %retval.0
}
declare dso_local i32 @foo(i32)
[Attributor][Tests][NFC] Add more range tests Inspired by https://llvm.discourse.group/t/impossible-condition-optimization/461
2020-02-10 09:06:09 +08:00
; Examples taken from https://llvm.discourse.group/t/impossible-condition-optimization/461/1
;
; The important part is that we return a constant (false)
;
; {
; FIXME: All but the return is not needed anymore
define dso_local zeroext i1 @phi(i32 %arg) {
[Attributor] Allow PHI nodes in AAValueConstantRangeFloating Traversing PHI nodes is natural with the genericValueTraversal but also a bit tricky. The problem is similar to the ones we have seen in AAAlign and AADereferenceable, namely that we continue to increase the range in each iteration. We use a pessimistic approach here to stop the iterations. Nevertheless, optimistic information can now be propagated through a PHI node.
2020-02-10 10:14:35 +08:00
; CHECK-LABEL: define {{[^@]+}}@phi
; CHECK-SAME: (i32 [[ARG:%.*]])
; CHECK-NEXT: bb:
; CHECK-NEXT: [[TMP:%.*]] = icmp sgt i32 [[ARG]], 5
; CHECK-NEXT: br i1 [[TMP]], label [[BB1:%.*]], label [[BB2:%.*]]
; CHECK: bb1:
; CHECK-NEXT: br label [[BB3:%.*]]
; CHECK: bb2:
; CHECK-NEXT: br label [[BB3]]
; CHECK: bb3:
; CHECK-NEXT: [[TMP4:%.*]] = icmp sgt i32 [[ARG]], 10
; CHECK-NEXT: br i1 [[TMP4]], label [[BB5:%.*]], label [[BB7:%.*]]
; CHECK: bb5:
; CHECK-NEXT: br label [[BB9:%.*]]
; CHECK: bb7:
; CHECK-NEXT: br label [[BB9]]
; CHECK: bb9:
; CHECK-NEXT: br label [[BB12:%.*]]
; CHECK: bb11:
; CHECK-NEXT: unreachable
; CHECK: bb12:
; CHECK-NEXT: br label [[BB13:%.*]]
; CHECK: bb13:
; CHECK-NEXT: ret i1 false
[Attributor][Tests][NFC] Add more range tests Inspired by https://llvm.discourse.group/t/impossible-condition-optimization/461
2020-02-10 09:06:09 +08:00
;
bb:
%tmp = icmp sgt i32 %arg, 5
br i1 %tmp, label %bb1, label %bb2
bb1: ; preds = %bb
br label %bb3
bb2: ; preds = %bb
br label %bb3
bb3: ; preds = %bb2, %bb1
%.02 = phi i32 [ 1, %bb1 ], [ 2, %bb2 ]
%tmp4 = icmp sgt i32 %arg, 10
br i1 %tmp4, label %bb5, label %bb7
bb5: ; preds = %bb3
%tmp6 = add nsw i32 %.02, 1
br label %bb9
bb7: ; preds = %bb3
%tmp8 = add nsw i32 %.02, 2
br label %bb9
bb9: ; preds = %bb7, %bb5
%.01 = phi i32 [ %tmp6, %bb5 ], [ %tmp8, %bb7 ]
%tmp10 = icmp eq i32 %.01, 5
br i1 %tmp10, label %bb11, label %bb12
bb11: ; preds = %bb9
br label %bb13
bb12: ; preds = %bb9
br label %bb13
bb13: ; preds = %bb12, %bb11
%.0 = phi i1 [ true, %bb11 ], [ false, %bb12 ]
ret i1 %.0
}
define dso_local i1 @select(i32 %a) local_unnamed_addr #0 {
[Attributor] Allow SelectInst in AAValueConstantRangeFloating The genericValueTraversal will already handle SelectInst properly and we just needed to allow them in the initialize method.
2020-02-10 09:08:04 +08:00
; CHECK-LABEL: define {{[^@]+}}@select
; CHECK-SAME: (i32 [[A:%.*]]) local_unnamed_addr
; CHECK-NEXT: entry:
; CHECK-NEXT: ret i1 false
[Attributor][Tests][NFC] Add more range tests Inspired by https://llvm.discourse.group/t/impossible-condition-optimization/461
2020-02-10 09:06:09 +08:00
;
entry:
%cmp = icmp sgt i32 %a, 5
%. = select i1 %cmp, i32 1, i32 2
%cmp1 = icmp sgt i32 %a, 10
%y.0.v = select i1 %cmp1, i32 1, i32 2
%y.0 = add nuw nsw i32 %., %y.0.v
%cmp6 = icmp eq i32 %y.0, 5
ret i1 %cmp6
}
define dso_local i32 @select_zext(i32 %a) local_unnamed_addr #0 {
[Attributor] Allow SelectInst in AAValueConstantRangeFloating The genericValueTraversal will already handle SelectInst properly and we just needed to allow them in the initialize method.
2020-02-10 09:08:04 +08:00
; CHECK-LABEL: define {{[^@]+}}@select_zext
; CHECK-SAME: (i32 [[A:%.*]]) local_unnamed_addr
; CHECK-NEXT: entry:
; CHECK-NEXT: ret i32 0
[Attributor] Look through (some) casts in AAValueConstantRangeFloating Casts can be handled natively by the ConstantRange class. We do limit it to extends for now as we assume an integer type in different locations. A TODO and a test case with a FIXME was added to remove that restriction in the future.
2020-02-10 09:07:30 +08:00
;
entry:
%cmp = icmp sgt i32 %a, 5
%. = select i1 %cmp, i32 1, i32 2
%cmp1 = icmp sgt i32 %a, 10
%y.0.v = select i1 %cmp1, i32 1, i32 2
%y.0 = add nuw nsw i32 %., %y.0.v
%cmp6 = icmp eq i32 %y.0, 5
%.13 = zext i1 %cmp6 to i32
ret i32 %.13
}
; FIXME: We do not look through the ptr casts here.
define dso_local i64 @select_int2ptr_bitcast_ptr2int(i32 %a) local_unnamed_addr #0 {
; CHECK-LABEL: define {{[^@]+}}@select_int2ptr_bitcast_ptr2int
[Attributor][Tests][NFC] Add more range tests Inspired by https://llvm.discourse.group/t/impossible-condition-optimization/461
2020-02-10 09:06:09 +08:00
; CHECK-SAME: (i32 [[A:%.*]]) local_unnamed_addr
; CHECK-NEXT: entry:
[Attributor] Add initial AAIsDead for arguments We usually will ask for liveness of an argument anyway so we ended up lazily creating the attribute anyway. However, that is not always the case and even if it is we should go the eager route here. Various tests show how this can improve the outcome. One test exposed a problem with type mismatches between argument and call site argument, a fix is included. For liveness various more tests were added as well.
2020-02-17 06:42:47 +08:00
; CHECK-NEXT: [[I2P:%.*]] = inttoptr i1 false to i1*
[Attributor] Look through (some) casts in AAValueConstantRangeFloating Casts can be handled natively by the ConstantRange class. We do limit it to extends for now as we assume an integer type in different locations. A TODO and a test case with a FIXME was added to remove that restriction in the future.
2020-02-10 09:07:30 +08:00
; CHECK-NEXT: [[BC:%.*]] = bitcast i1* [[I2P]] to i32*
; CHECK-NEXT: [[P2I:%.*]] = ptrtoint i32* [[BC]] to i64
; CHECK-NEXT: ret i64 [[P2I]]
[Attributor][Tests][NFC] Add more range tests Inspired by https://llvm.discourse.group/t/impossible-condition-optimization/461
2020-02-10 09:06:09 +08:00
;
entry:
%cmp = icmp sgt i32 %a, 5
%. = select i1 %cmp, i32 1, i32 2
%cmp1 = icmp sgt i32 %a, 10
%y.0.v = select i1 %cmp1, i32 1, i32 2
%y.0 = add nuw nsw i32 %., %y.0.v
%cmp6 = icmp eq i32 %y.0, 5
[Attributor] Look through (some) casts in AAValueConstantRangeFloating Casts can be handled natively by the ConstantRange class. We do limit it to extends for now as we assume an integer type in different locations. A TODO and a test case with a FIXME was added to remove that restriction in the future.
2020-02-10 09:07:30 +08:00
%i2p = inttoptr i1 %cmp6 to i1*
%bc = bitcast i1* %i2p to i32*
%p2i = ptrtoint i32* %bc to i64
ret i64 %p2i
[Attributor][Tests][NFC] Add more range tests Inspired by https://llvm.discourse.group/t/impossible-condition-optimization/461
2020-02-10 09:06:09 +08:00
}
; }
[Attributor][FIX] Validate the type for AAValueConstantRange as needed Due to the genericValueTraversal we might visit values for which we did not create an AAValueConstantRange object, e.g., as they are behind a PHI or select or call with `returned` argument. As a consequence we need to validate the types as we are about to query AAValueConstantRange for operands.
2020-02-14 04:22:26 +08:00
define i1 @f_fcmp(float %a, float %b) {
[Attributor][NFC] Add check lines for tests
2020-02-15 09:27:41 +08:00
; CHECK-LABEL: define {{[^@]+}}@f_fcmp
; CHECK-SAME: (float [[A:%.*]], float [[B:%.*]])
; CHECK-NEXT: [[R:%.*]] = fcmp uge float [[A]], [[B]]
; CHECK-NEXT: [[S:%.*]] = select i1 [[R]], i1 [[R]], i1 false
; CHECK-NEXT: ret i1 [[S]]
;
[Attributor][FIX] Validate the type for AAValueConstantRange as needed Due to the genericValueTraversal we might visit values for which we did not create an AAValueConstantRange object, e.g., as they are behind a PHI or select or call with `returned` argument. As a consequence we need to validate the types as we are about to query AAValueConstantRange for operands.
2020-02-14 04:22:26 +08:00
%r = fcmp uge float %a, %b
%s = select i1 %r, i1 %r, i1 0
ret i1 %s
}
define i1 @d_fcmp(double %a, double %b) {
[Attributor][NFC] Add check lines for tests
2020-02-15 09:27:41 +08:00
; CHECK-LABEL: define {{[^@]+}}@d_fcmp
; CHECK-SAME: (double [[A:%.*]], double [[B:%.*]])
; CHECK-NEXT: [[R:%.*]] = fcmp oeq double [[A]], [[B]]
; CHECK-NEXT: [[S:%.*]] = select i1 [[R]], i1 [[R]], i1 false
; CHECK-NEXT: ret i1 [[S]]
;
[Attributor][FIX] Validate the type for AAValueConstantRange as needed Due to the genericValueTraversal we might visit values for which we did not create an AAValueConstantRange object, e.g., as they are behind a PHI or select or call with `returned` argument. As a consequence we need to validate the types as we are about to query AAValueConstantRange for operands.
2020-02-14 04:22:26 +08:00
%r = fcmp oeq double %a, %b
%s = select i1 %r, i1 %r, i1 0
ret i1 %s
}
define i1 @dp_icmp(double* %a, double* %b) {
[Attributor][NFC] Add check lines for tests
2020-02-15 09:27:41 +08:00
; CHECK-LABEL: define {{[^@]+}}@dp_icmp
; CHECK-SAME: (double* nofree readnone [[A:%.*]], double* nofree readnone [[B:%.*]])
; CHECK-NEXT: [[R:%.*]] = icmp sge double* [[A]], [[B]]
; CHECK-NEXT: [[S:%.*]] = select i1 [[R]], i1 [[R]], i1 false
; CHECK-NEXT: ret i1 [[S]]
;
[Attributor][FIX] Validate the type for AAValueConstantRange as needed Due to the genericValueTraversal we might visit values for which we did not create an AAValueConstantRange object, e.g., as they are behind a PHI or select or call with `returned` argument. As a consequence we need to validate the types as we are about to query AAValueConstantRange for operands.
2020-02-14 04:22:26 +08:00
%r = icmp sge double* %a, %b
%s = select i1 %r, i1 %r, i1 0
ret i1 %s
}
define i1 @ip_icmp(i8* %a, i8* %b) {
[Attributor][NFC] Add check lines for tests
2020-02-15 09:27:41 +08:00
; CHECK-LABEL: define {{[^@]+}}@ip_icmp
; CHECK-SAME: (i8* nofree readnone [[A:%.*]], i8* nofree readnone [[B:%.*]])
; CHECK-NEXT: [[R:%.*]] = icmp ult i8* [[A]], [[B]]
; CHECK-NEXT: [[S:%.*]] = select i1 [[R]], i1 [[R]], i1 false
; CHECK-NEXT: ret i1 [[S]]
;
[Attributor][FIX] Validate the type for AAValueConstantRange as needed Due to the genericValueTraversal we might visit values for which we did not create an AAValueConstantRange object, e.g., as they are behind a PHI or select or call with `returned` argument. As a consequence we need to validate the types as we are about to query AAValueConstantRange for operands.
2020-02-14 04:22:26 +08:00
%r = icmp ult i8* %a, %b
%s = select i1 %r, i1 %r, i1 0
ret i1 %s
}
define i1 @fcmp_caller(float %fa, float %fb, double %da, double %db, double* %dpa, double* %dpb, i8* %ipa, i8* %ipb) {
[Attributor][NFC] Add check lines for tests
2020-02-15 09:27:41 +08:00
; CHECK-LABEL: define {{[^@]+}}@fcmp_caller
; CHECK-SAME: (float [[FA:%.*]], float [[FB:%.*]], double [[DA:%.*]], double [[DB:%.*]], double* nofree readnone [[DPA:%.*]], double* nofree readnone [[DPB:%.*]], i8* nofree readnone [[IPA:%.*]], i8* nofree readnone [[IPB:%.*]])
; CHECK-NEXT: [[R1:%.*]] = call i1 @f_fcmp(float [[FA]], float [[FB]])
; CHECK-NEXT: [[R2:%.*]] = call i1 @d_fcmp(double [[DA]], double [[DB]])
; CHECK-NEXT: [[R3:%.*]] = call i1 @dp_icmp(double* noalias nofree readnone [[DPA]], double* noalias nofree readnone [[DPB]])
; CHECK-NEXT: [[R4:%.*]] = call i1 @ip_icmp(i8* noalias nofree readnone [[IPA]], i8* noalias nofree readnone [[IPB]])
; CHECK-NEXT: [[O1:%.*]] = or i1 [[R1]], [[R2]]
; CHECK-NEXT: [[O2:%.*]] = or i1 [[R3]], [[R4]]
; CHECK-NEXT: [[O3:%.*]] = or i1 [[O1]], [[O2]]
; CHECK-NEXT: ret i1 [[O3]]
;
[Attributor][FIX] Validate the type for AAValueConstantRange as needed Due to the genericValueTraversal we might visit values for which we did not create an AAValueConstantRange object, e.g., as they are behind a PHI or select or call with `returned` argument. As a consequence we need to validate the types as we are about to query AAValueConstantRange for operands.
2020-02-14 04:22:26 +08:00
%r1 = call i1 @f_fcmp(float %fa, float %fb)
%r2 = call i1 @d_fcmp(double %da, double %db)
%r3 = call i1 @dp_icmp(double* %dpa, double* %dpb)
%r4 = call i1 @ip_icmp(i8* %ipa, i8* %ipb)
%o1 = or i1 %r1, %r2
%o2 = or i1 %r3, %r4
%o3 = or i1 %o1, %o2
ret i1 %o3
}
[Attributor][FIX] Collapse `undef` to a proper value If we see an undef we cannot assume it's the same as "no value". For now we just collapse it to 0.
2020-02-15 10:08:20 +08:00
define i8 @ret_two() {
; CHECK-LABEL: define {{[^@]+}}@ret_two()
; CHECK-NEXT: ret i8 2
;
ret i8 2
}
define i8 @ret_undef() {
; CHECK-LABEL: define {{[^@]+}}@ret_undef()
; CHECK-NEXT: ret i8 undef
;
ret i8 undef
}
; Verify we collapse undef to a value and return something non-undef here.
define i8 @undef_collapse_1() {
; CHECK-LABEL: define {{[^@]+}}@undef_collapse_1()
; CHECK-NEXT: ret i8 0
;
%c = call i8 @ret_undef()
%s = shl i8 %c, 2
ret i8 %s
}
; Verify we collapse undef to a value and return something non-undef here.
define i8 @undef_collapse_2() {
; CHECK-LABEL: define {{[^@]+}}@undef_collapse_2()
; CHECK-NEXT: ret i8 0
;
%c = call i8 @ret_two()
%s = shl i8 undef, %c
ret i8 %s
}
define i8 @undef_collapse_caller() {
;
[Attributor] Unify testing (=updates,prefixes,run configurations,...) When the Attributor was created the test update scripts were not well suited to deal with the challenges of IR attribute checking. This partially improved. Since then we also added three additional configurations that need testing; in total we now have the following four: { TUNIT, CGSCC } x { old pass manager (OPM), new pass manager (NPM) } Finally, the number of developers and tests grew rapidly (partially due to the addition of ArgumentPromotion and IPConstantProp tests), which resulted in tests only being run in some configurations, different prefixes being used, and different "styles" of checks being used. Due to the above reasons I believed we needed to take another look at the test update scripts. While we started to use them, via UTC_ARGS: --enable/disable, the other problems remained. To improve the testing situation for *all* configurations, to simplify future updates to the test, and to help identify subtle effects of future changes, we now use the test update scripts for (almost) all Attributor tests. An exhaustive prefix list minimizes the number of check lines and makes it easy to identify and compare configurations. Tests have been adjusted in the process but we tried to keep their intend unchanged. Reviewed By: sstefan1 Differential Revision: https://reviews.llvm.org/D76588
2020-04-09 08:04:57 +08:00
; IS__TUNIT____-LABEL: define {{[^@]+}}@undef_collapse_caller()
; IS__TUNIT____-NEXT: ret i8 0
[Attributor][FIX] Collapse `undef` to a proper value If we see an undef we cannot assume it's the same as "no value". For now we just collapse it to 0.
2020-02-15 10:08:20 +08:00
;
[Attributor] Unify testing (=updates,prefixes,run configurations,...) When the Attributor was created the test update scripts were not well suited to deal with the challenges of IR attribute checking. This partially improved. Since then we also added three additional configurations that need testing; in total we now have the following four: { TUNIT, CGSCC } x { old pass manager (OPM), new pass manager (NPM) } Finally, the number of developers and tests grew rapidly (partially due to the addition of ArgumentPromotion and IPConstantProp tests), which resulted in tests only being run in some configurations, different prefixes being used, and different "styles" of checks being used. Due to the above reasons I believed we needed to take another look at the test update scripts. While we started to use them, via UTC_ARGS: --enable/disable, the other problems remained. To improve the testing situation for *all* configurations, to simplify future updates to the test, and to help identify subtle effects of future changes, we now use the test update scripts for (almost) all Attributor tests. An exhaustive prefix list minimizes the number of check lines and makes it easy to identify and compare configurations. Tests have been adjusted in the process but we tried to keep their intend unchanged. Reviewed By: sstefan1 Differential Revision: https://reviews.llvm.org/D76588
2020-04-09 08:04:57 +08:00
; IS__CGSCC____-LABEL: define {{[^@]+}}@undef_collapse_caller()
; IS__CGSCC____-NEXT: [[C1:%.*]] = call i8 @undef_collapse_1()
; IS__CGSCC____-NEXT: [[C2:%.*]] = call i8 @undef_collapse_2()
; IS__CGSCC____-NEXT: [[A:%.*]] = add i8 [[C1]], [[C2]]
; IS__CGSCC____-NEXT: ret i8 [[A]]
[Attributor][FIX] Collapse `undef` to a proper value If we see an undef we cannot assume it's the same as "no value". For now we just collapse it to 0.
2020-02-15 10:08:20 +08:00
;
%c1 = call i8 @undef_collapse_1()
%c2 = call i8 @undef_collapse_2()
%a = add i8 %c1, %c2
ret i8 %a
}
[Attributor] Handle calls in AAValueConstantRange properly We did handle calls that were operands of certain instructions but not standalone calls we visit via indirection, e.g., selects.
2020-03-20 14:37:27 +08:00
define i32 @ret1or2(i1 %c) {
; CHECK-LABEL: define {{[^@]+}}@ret1or2
; CHECK-SAME: (i1 [[C:%.*]])
; CHECK-NEXT: [[S:%.*]] = select i1 [[C]], i32 1, i32 2
; CHECK-NEXT: ret i32 [[S]]
;
%s = select i1 %c, i32 1, i32 2
ret i32 %s
}
define i1 @callee_range_1(i1 %c1, i1 %c2, i1 %c3) {
;
[Attributor] Unify testing (=updates,prefixes,run configurations,...) When the Attributor was created the test update scripts were not well suited to deal with the challenges of IR attribute checking. This partially improved. Since then we also added three additional configurations that need testing; in total we now have the following four: { TUNIT, CGSCC } x { old pass manager (OPM), new pass manager (NPM) } Finally, the number of developers and tests grew rapidly (partially due to the addition of ArgumentPromotion and IPConstantProp tests), which resulted in tests only being run in some configurations, different prefixes being used, and different "styles" of checks being used. Due to the above reasons I believed we needed to take another look at the test update scripts. While we started to use them, via UTC_ARGS: --enable/disable, the other problems remained. To improve the testing situation for *all* configurations, to simplify future updates to the test, and to help identify subtle effects of future changes, we now use the test update scripts for (almost) all Attributor tests. An exhaustive prefix list minimizes the number of check lines and makes it easy to identify and compare configurations. Tests have been adjusted in the process but we tried to keep their intend unchanged. Reviewed By: sstefan1 Differential Revision: https://reviews.llvm.org/D76588
2020-04-09 08:04:57 +08:00
; IS__TUNIT____-LABEL: define {{[^@]+}}@callee_range_1
; IS__TUNIT____-SAME: (i1 [[C1:%.*]], i1 [[C2:%.*]], i1 [[C3:%.*]])
; IS__TUNIT____-NEXT: ret i1 true
;
; IS__CGSCC____-LABEL: define {{[^@]+}}@callee_range_1
; IS__CGSCC____-SAME: (i1 [[C1:%.*]], i1 [[C2:%.*]], i1 [[C3:%.*]])
; IS__CGSCC____-NEXT: [[R1:%.*]] = call i32 @ret1or2(i1 [[C1]])
; IS__CGSCC____-NEXT: [[R2:%.*]] = call i32 @ret1or2(i1 [[C2]])
; IS__CGSCC____-NEXT: [[INDIRECTION:%.*]] = select i1 [[C3]], i32 [[R1]], i32 [[R2]]
; IS__CGSCC____-NEXT: [[A:%.*]] = add i32 [[R1]], [[INDIRECTION]]
; IS__CGSCC____-NEXT: [[I1:%.*]] = icmp sle i32 [[A]], 4
; IS__CGSCC____-NEXT: [[I2:%.*]] = icmp sge i32 [[A]], 2
; IS__CGSCC____-NEXT: [[F:%.*]] = and i1 [[I1]], [[I2]]
; IS__CGSCC____-NEXT: ret i1 [[F]]
[Attributor] Handle calls in AAValueConstantRange properly We did handle calls that were operands of certain instructions but not standalone calls we visit via indirection, e.g., selects.
2020-03-20 14:37:27 +08:00
;
%r1 = call i32 @ret1or2(i1 %c1)
%r2 = call i32 @ret1or2(i1 %c2)
%indirection = select i1 %c3, i32 %r1, i32 %r2
%a = add i32 %r1, %indirection
%i1 = icmp sle i32 %a, 4
%i2 = icmp sge i32 %a, 2
%f = and i1 %i1, %i2
ret i1 %f
}
define i1 @callee_range_2(i1 %c1, i1 %c2) {
;
[Attributor] Unify testing (=updates,prefixes,run configurations,...) When the Attributor was created the test update scripts were not well suited to deal with the challenges of IR attribute checking. This partially improved. Since then we also added three additional configurations that need testing; in total we now have the following four: { TUNIT, CGSCC } x { old pass manager (OPM), new pass manager (NPM) } Finally, the number of developers and tests grew rapidly (partially due to the addition of ArgumentPromotion and IPConstantProp tests), which resulted in tests only being run in some configurations, different prefixes being used, and different "styles" of checks being used. Due to the above reasons I believed we needed to take another look at the test update scripts. While we started to use them, via UTC_ARGS: --enable/disable, the other problems remained. To improve the testing situation for *all* configurations, to simplify future updates to the test, and to help identify subtle effects of future changes, we now use the test update scripts for (almost) all Attributor tests. An exhaustive prefix list minimizes the number of check lines and makes it easy to identify and compare configurations. Tests have been adjusted in the process but we tried to keep their intend unchanged. Reviewed By: sstefan1 Differential Revision: https://reviews.llvm.org/D76588
2020-04-09 08:04:57 +08:00
; IS__TUNIT_OPM-LABEL: define {{[^@]+}}@callee_range_2
; IS__TUNIT_OPM-SAME: (i1 [[C1:%.*]], i1 [[C2:%.*]])
; IS__TUNIT_OPM-NEXT: [[R1:%.*]] = call i32 @ret1or2(i1 [[C1]]) #2, !range !4
; IS__TUNIT_OPM-NEXT: [[R2:%.*]] = call i32 @ret1or2(i1 [[C2]]) #3, !range !4
; IS__TUNIT_OPM-NEXT: [[A:%.*]] = add i32 [[R1]], [[R2]]
; IS__TUNIT_OPM-NEXT: [[I1:%.*]] = icmp sle i32 [[A]], 3
; IS__TUNIT_OPM-NEXT: [[I2:%.*]] = icmp sge i32 [[A]], 2
; IS__TUNIT_OPM-NEXT: [[F:%.*]] = and i1 [[I1]], [[I2]]
; IS__TUNIT_OPM-NEXT: ret i1 [[F]]
;
; IS__TUNIT_NPM-LABEL: define {{[^@]+}}@callee_range_2
; IS__TUNIT_NPM-SAME: (i1 [[C1:%.*]], i1 [[C2:%.*]])
; IS__TUNIT_NPM-NEXT: [[R1:%.*]] = call i32 @ret1or2(i1 [[C1]]) #2, !range !5
; IS__TUNIT_NPM-NEXT: [[R2:%.*]] = call i32 @ret1or2(i1 [[C2]]) #3, !range !5
; IS__TUNIT_NPM-NEXT: [[A:%.*]] = add i32 [[R1]], [[R2]]
; IS__TUNIT_NPM-NEXT: [[I1:%.*]] = icmp sle i32 [[A]], 3
; IS__TUNIT_NPM-NEXT: [[I2:%.*]] = icmp sge i32 [[A]], 2
; IS__TUNIT_NPM-NEXT: [[F:%.*]] = and i1 [[I1]], [[I2]]
; IS__TUNIT_NPM-NEXT: ret i1 [[F]]
;
; IS__CGSCC____-LABEL: define {{[^@]+}}@callee_range_2
; IS__CGSCC____-SAME: (i1 [[C1:%.*]], i1 [[C2:%.*]])
; IS__CGSCC____-NEXT: [[R1:%.*]] = call i32 @ret1or2(i1 [[C1]])
; IS__CGSCC____-NEXT: [[R2:%.*]] = call i32 @ret1or2(i1 [[C2]])
; IS__CGSCC____-NEXT: [[A:%.*]] = add i32 [[R1]], [[R2]]
; IS__CGSCC____-NEXT: [[I1:%.*]] = icmp sle i32 [[A]], 3
; IS__CGSCC____-NEXT: [[I2:%.*]] = icmp sge i32 [[A]], 2
; IS__CGSCC____-NEXT: [[F:%.*]] = and i1 [[I1]], [[I2]]
; IS__CGSCC____-NEXT: ret i1 [[F]]
[Attributor] Handle calls in AAValueConstantRange properly We did handle calls that were operands of certain instructions but not standalone calls we visit via indirection, e.g., selects.
2020-03-20 14:37:27 +08:00
;
%r1 = call i32 @ret1or2(i1 %c1)
%r2 = call i32 @ret1or2(i1 %c2)
%a = add i32 %r1, %r2
%i1 = icmp sle i32 %a, 3
%i2 = icmp sge i32 %a, 2
%f = and i1 %i1, %i2
ret i1 %f
}
[Attributor][FIX] Collapse `undef` to a proper value If we see an undef we cannot assume it's the same as "no value". For now we just collapse it to 0.
2020-02-15 10:08:20 +08:00
[Attributor] Use the proper context instruction in genericValueTraversal There was a TODO in genericValueTraversal to provide the context instruction and due to the lack of it users that wanted one just used something available. Unfortunately, using a fixed instruction is wrong in the presence of PHIs so we need to update the context instruction properly. Reviewed By: uenoku Differential Revision: https://reviews.llvm.org/D76870
2020-04-02 11:05:24 +08:00
define i32 @ret100() {
; CHECK-LABEL: define {{[^@]+}}@ret100()
; CHECK-NEXT: ret i32 100
;
ret i32 100
}
define i1 @ctx_adjustment(i32 %V) {
;
[Attributor] Unify testing (=updates,prefixes,run configurations,...) When the Attributor was created the test update scripts were not well suited to deal with the challenges of IR attribute checking. This partially improved. Since then we also added three additional configurations that need testing; in total we now have the following four: { TUNIT, CGSCC } x { old pass manager (OPM), new pass manager (NPM) } Finally, the number of developers and tests grew rapidly (partially due to the addition of ArgumentPromotion and IPConstantProp tests), which resulted in tests only being run in some configurations, different prefixes being used, and different "styles" of checks being used. Due to the above reasons I believed we needed to take another look at the test update scripts. While we started to use them, via UTC_ARGS: --enable/disable, the other problems remained. To improve the testing situation for *all* configurations, to simplify future updates to the test, and to help identify subtle effects of future changes, we now use the test update scripts for (almost) all Attributor tests. An exhaustive prefix list minimizes the number of check lines and makes it easy to identify and compare configurations. Tests have been adjusted in the process but we tried to keep their intend unchanged. Reviewed By: sstefan1 Differential Revision: https://reviews.llvm.org/D76588
2020-04-09 08:04:57 +08:00
; IS________OPM-LABEL: define {{[^@]+}}@ctx_adjustment
; IS________OPM-SAME: (i32 [[V:%.*]])
; IS________OPM-NEXT: [[C1:%.*]] = icmp sge i32 [[V]], 100
; IS________OPM-NEXT: br i1 [[C1]], label [[IF_TRUE:%.*]], label [[IF_FALSE:%.*]]
; IS________OPM: if.true:
; IS________OPM-NEXT: br label [[END:%.*]]
; IS________OPM: if.false:
; IS________OPM-NEXT: br label [[END]]
; IS________OPM: end:
; IS________OPM-NEXT: [[PHI:%.*]] = phi i32 [ [[V]], [[IF_TRUE]] ], [ 100, [[IF_FALSE]] ]
; IS________OPM-NEXT: [[C2:%.*]] = icmp sge i32 [[PHI]], 100
; IS________OPM-NEXT: ret i1 [[C2]]
;
; IS________NPM-LABEL: define {{[^@]+}}@ctx_adjustment
; IS________NPM-SAME: (i32 [[V:%.*]])
; IS________NPM-NEXT: [[C1:%.*]] = icmp sge i32 [[V]], 100
; IS________NPM-NEXT: br i1 [[C1]], label [[IF_TRUE:%.*]], label [[IF_FALSE:%.*]]
; IS________NPM: if.true:
; IS________NPM-NEXT: br label [[END:%.*]]
; IS________NPM: if.false:
; IS________NPM-NEXT: br label [[END]]
; IS________NPM: end:
; IS________NPM-NEXT: ret i1 true
[Attributor] Use the proper context instruction in genericValueTraversal There was a TODO in genericValueTraversal to provide the context instruction and due to the lack of it users that wanted one just used something available. Unfortunately, using a fixed instruction is wrong in the presence of PHIs so we need to update the context instruction properly. Reviewed By: uenoku Differential Revision: https://reviews.llvm.org/D76870
2020-04-02 11:05:24 +08:00
;
%c1 = icmp sge i32 %V, 100
br i1 %c1, label %if.true, label %if.false
if.true:
br label %end
if.false:
%call = call i32 @ret100()
br label %end
end:
%phi = phi i32 [ %V, %if.true ], [ %call, %if.false ]
%c2 = icmp sge i32 %phi, 100
ret i1 %c2
}
[Attributor] AAValueConstantRange: Value range analysis using constant range Summary: This patch introduces `AAValueConstantRange`, which answers a possible range for integer value in a specific program point. One of the motivations is propagating existing `range` metadata. (I think we need to change the situation that `range` metadata cannot be put to Argument). The state is a tuple of `ConstantRange` and it is initialized to (known, assumed) = ([-∞, +∞], empty). Currently, AAValueConstantRange is created in `getAssumedConstant` method when `AAValueSimplify` returns `nullptr`(worst state). Supported - BinaryOperator(add, sub, ...) - CmpInst(icmp eq, ...) - !range metadata `AAValueConstantRange` is not intended to extend to polyhedral range value analysis. Reviewers: jdoerfert, sstefan1 Reviewed By: jdoerfert Subscribers: phosek, davezarzycki, baziotis, hiraditya, javed.absar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71620
2020-01-15 14:25:52 +08:00
!0 = !{i32 0, i32 10}
!1 = !{i32 10, i32 100}
[Attributor] Unify testing (=updates,prefixes,run configurations,...) When the Attributor was created the test update scripts were not well suited to deal with the challenges of IR attribute checking. This partially improved. Since then we also added three additional configurations that need testing; in total we now have the following four: { TUNIT, CGSCC } x { old pass manager (OPM), new pass manager (NPM) } Finally, the number of developers and tests grew rapidly (partially due to the addition of ArgumentPromotion and IPConstantProp tests), which resulted in tests only being run in some configurations, different prefixes being used, and different "styles" of checks being used. Due to the above reasons I believed we needed to take another look at the test update scripts. While we started to use them, via UTC_ARGS: --enable/disable, the other problems remained. To improve the testing situation for *all* configurations, to simplify future updates to the test, and to help identify subtle effects of future changes, we now use the test update scripts for (almost) all Attributor tests. An exhaustive prefix list minimizes the number of check lines and makes it easy to identify and compare configurations. Tests have been adjusted in the process but we tried to keep their intend unchanged. Reviewed By: sstefan1 Differential Revision: https://reviews.llvm.org/D76588
2020-04-09 08:04:57 +08:00
; NOT_TUNIT____: !0 = !{i32 0, i32 10}
; NOT_TUNIT____: !1 = !{i32 10, i32 100}
; NOT_TUNIT____-NOT: !2
; IS__TUNIT_OPM: !0 = !{i32 0, i32 10}
; IS__TUNIT_OPM: !1 = !{i32 10, i32 100}
; IS__TUNIT_OPM: !2 = !{i32 200, i32 1091}
; IS__TUNIT_OPM: !3 = !{i32 0, i32 2}
; IS__TUNIT_OPM: !4 = !{i32 1, i32 3}
; IS__TUNIT_OPM-NOT: !5
; IS__TUNIT_NPM: !0 = !{i32 0, i32 10}
; IS__TUNIT_NPM: !1 = !{i32 10, i32 100}
; IS__TUNIT_NPM: !2 = !{i32 200, i32 1091}
; IS__TUNIT_NPM: !3 = !{i32 1, i32 -2147483648}
; IS__TUNIT_NPM: !4 = !{i32 0, i32 2}
; IS__TUNIT_NPM: !5 = !{i32 1, i32 3}
; IS__TUNIT_NPM-NOT: !6