maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/Analysis/ScalarEvolution/sext-inreg.ll

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

37 lines
1.3 KiB
LLVM
Raw Normal View History

[SCEV] Fix ScalarEvolution tests under NPM Many tests use opt's -analyze feature, which does not translate well to NPM and has better alternatives. The alternative here is to explicitly add a pass that calls ScalarEvolution::print(). The legacy pass manager RUNs aren't changing, but they are now pinned to the legacy pass manager. For each legacy pass manager RUN, I added a corresponding NPM RUN using the 'print<scalar-evolution>' pass. For compatibility with update_analyze_test_checks.py and existing test CHECKs, 'print<scalar-evolution>' now prints what -analyze prints per function. This was generated by the following Python script and failures were manually fixed up: import sys for i in sys.argv: with open(i, 'r') as f: s = f.read() with open(i, 'w') as f: for l in s.splitlines(): if "RUN:" in l and ' -analyze ' in l and '\\' not in l: f.write(l.replace(' -analyze ', ' -analyze -enable-new-pm=0 ')) f.write('\n') f.write(l.replace(' -analyze ', ' -disable-output ').replace(' -scalar-evolution ', ' "-passes=print<scalar-evolution>" ').replace(" | ", " 2>&1 | ")) f.write('\n') else: f.write(l) There are a couple failures still in ScalarEvolution under NPM, but those are due to other unrelated naming conflicts. Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D83798
2020-07-17 02:09:47 +08:00
; RUN: opt < %s -analyze -enable-new-pm=0 -scalar-evolution | FileCheck %s
; RUN: opt < %s -disable-output "-passes=print<scalar-evolution>" 2>&1 | FileCheck %s
When turning (ashr(shl(x, n), n)) into sext(trunc(x)), the width of the type to truncate to should be the number of bits of the value that are preserved, not the number that are clobbered with sign-extension. This fixes regressions in ldecod. llvm-svn: 69704
2009-04-22 04:18:36 +08:00
target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:128:128"
target triple = "i386-apple-darwin9.6"
define i64 @foo(i64* nocapture %x, i64 %n) nounwind {
[SCEV] Un-grep'ify tests; NFC llvm-svn: 277861
2016-08-06 04:33:49 +08:00
; CHECK-LABEL: Classifying expressions for: @foo
When turning (ashr(shl(x, n), n)) into sext(trunc(x)), the width of the type to truncate to should be the number of bits of the value that are preserved, not the number that are clobbered with sign-extension. This fixes regressions in ldecod. llvm-svn: 69704
2009-04-22 04:18:36 +08:00
entry:
[SCEV] Un-grep'ify tests; NFC llvm-svn: 277861
2016-08-06 04:33:49 +08:00
%t0 = icmp sgt i64 %n, 0
When turning (ashr(shl(x, n), n)) into sext(trunc(x)), the width of the type to truncate to should be the number of bits of the value that are preserved, not the number that are clobbered with sign-extension. This fixes regressions in ldecod. llvm-svn: 69704
2009-04-22 04:18:36 +08:00
br i1 %t0, label %bb, label %return
[SCEV] Un-grep'ify tests; NFC llvm-svn: 277861
2016-08-06 04:33:49 +08:00
bb:
%i.01 = phi i64 [ 0, %entry ], [ %indvar.next, %bb ]
%t1 = shl i64 %i.01, 7
%t2 = ashr i64 %t1, 7
; CHECK: %t2 = ashr i64 %t1, 7
; CHECK-NEXT: sext i57 {0,+,199}<%bb> to i64
[SCEV] Simplify trunc-of-add/mul to add/mul-of-trunc under more circumstances. Summary: Previously we would do this simplification only if it did not introduce any new truncs (excepting new truncs which replace other cast ops). This change weakens this condition: If the number of truncs stays the same, but we're able to transform trunc(X + Y) to X + trunc(Y), that's still simpler, and it may open up additional transformations. While we're here, also clean up some duplicated code. Reviewers: sanjoy Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D48160 llvm-svn: 334736
2018-06-15 01:13:35 +08:00
; CHECK-SAME: Exits: (sext i57 (-199 + (trunc i64 %n to i57)) to i64)
[SCEV] Un-grep'ify tests; NFC llvm-svn: 277861
2016-08-06 04:33:49 +08:00
; CHECK: %s2 = ashr i64 %s1, 5
; CHECK-NEXT: sext i59 {0,+,199}<%bb> to i64
[SCEV] Simplify trunc-of-add/mul to add/mul-of-trunc under more circumstances. Summary: Previously we would do this simplification only if it did not introduce any new truncs (excepting new truncs which replace other cast ops). This change weakens this condition: If the number of truncs stays the same, but we're able to transform trunc(X + Y) to X + trunc(Y), that's still simpler, and it may open up additional transformations. While we're here, also clean up some duplicated code. Reviewers: sanjoy Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D48160 llvm-svn: 334736
2018-06-15 01:13:35 +08:00
; CHECK-SAME: Exits: (sext i59 (-199 + (trunc i64 %n to i59)) to i64)
[SCEV] Un-grep'ify tests; NFC llvm-svn: 277861
2016-08-06 04:33:49 +08:00
%s1 = shl i64 %i.01, 5
%s2 = ashr i64 %s1, 5
%t3 = getelementptr i64, i64* %x, i64 %i.01
When turning (ashr(shl(x, n), n)) into sext(trunc(x)), the width of the type to truncate to should be the number of bits of the value that are preserved, not the number that are clobbered with sign-extension. This fixes regressions in ldecod. llvm-svn: 69704
2009-04-22 04:18:36 +08:00
store i64 0, i64* %t3, align 1
[SCEV] Un-grep'ify tests; NFC llvm-svn: 277861
2016-08-06 04:33:49 +08:00
%indvar.next = add i64 %i.01, 199
%exitcond = icmp eq i64 %indvar.next, %n
When turning (ashr(shl(x, n), n)) into sext(trunc(x)), the width of the type to truncate to should be the number of bits of the value that are preserved, not the number that are clobbered with sign-extension. This fixes regressions in ldecod. llvm-svn: 69704
2009-04-22 04:18:36 +08:00
br i1 %exitcond, label %return, label %bb
[SCEV] Un-grep'ify tests; NFC llvm-svn: 277861
2016-08-06 04:33:49 +08:00
return:
When turning (ashr(shl(x, n), n)) into sext(trunc(x)), the width of the type to truncate to should be the number of bits of the value that are preserved, not the number that are clobbered with sign-extension. This fixes regressions in ldecod. llvm-svn: 69704
2009-04-22 04:18:36 +08:00
%p = phi i64 [ 0, %entry ], [ %t2, %bb ]
%q = phi i64 [ 0, %entry ], [ %s2, %bb ]
%v = xor i64 %p, %q
ret i64 %v
}