llvm-project/llvm/test/Analysis/IVUsers/quadradic-exit-value.ll

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

96 lines
3.1 KiB
LLVM
Raw Normal View History

; This test ensures that IVUsers works correctly in the legacy pass manager
; without LCSSA and in the specific ways that some of its users (LSR) require.
;
; FIXME: We need some way to match the precision here in the new PM where loop
; passes *always* work on LCSSA. This should stop using a different set of
; checks at that point.
; RUN: opt < %s -analyze -iv-users | FileCheck %s --check-prefixes=CHECK,CHECK-NO-LCSSA
; RUN: opt < %s -disable-output -passes='print<iv-users>' 2>&1 | FileCheck %s
; Provide legal integer types.
target datalayout = "n8:16:32:64"
; The value of %r is dependent on a polynomial iteration expression.
;
; CHECK-LABEL: IV Users for loop %foo.loop
; CHECK-NO-LCSSA: {1,+,3,+,2}<%foo.loop>
define i64 @foo(i64 %n) {
entry:
br label %foo.loop
foo.loop:
%indvar = phi i64 [ 0, %entry ], [ %indvar.next, %foo.loop ]
%indvar.next = add i64 %indvar, 1
%c = icmp eq i64 %indvar.next, %n
br i1 %c, label %exit, label %foo.loop
exit:
%r = mul i64 %indvar.next, %indvar.next
ret i64 %r
}
Re-enable "[SCEV] Do not fold dominated SCEVUnknown into AddRecExpr start" The patch rL303730 was reverted because test lsr-expand-quadratic.ll failed on many non-X86 configs with this patch. The reason of this is that the patch makes a correctless fix that changes optimizer's behavior for this test. Without the change, LSR was making an overconfident simplification basing on a wrong SCEV. Apparently it did not need the IV analysis to do this. With the change, it chose a different way to simplify (that wasn't so confident), and this way required the IV analysis. Now, following the right execution path, LSR tries to make a transformation relying on IV Users analysis. This analysis is target-dependent due to this code: // LSR is not APInt clean, do not touch integers bigger than 64-bits. // Also avoid creating IVs of non-native types. For example, we don't want a // 64-bit IV in 32-bit code just because the loop has one 64-bit cast. uint64_t Width = SE->getTypeSizeInBits(I->getType()); if (Width > 64 || !DL.isLegalInteger(Width)) return false; To make a proper transformation in this test case, the type i32 needs to be legal for the specified data layout. When the test runs on some non-X86 configuration (e.g. pure ARM 64), opt gets confused by the specified target and does not use it, rejecting the specified data layout as well. Instead, it uses some default layout that does not treat i32 as a legal type (currently the layout that is used when it is not specified does not have legal types at all). As result, the transformation we expect to happen does not happen for this test. This re-enabling patch does not have any source code changes compared to the original patch rL303730. The only difference is that the failing test is moved to X86 directory and now has requirement of running on x86 only to comply with the specified target triple and data layout. Differential Revision: https://reviews.llvm.org/D33543 llvm-svn: 303971
2017-05-26 14:47:04 +08:00
; PR15470: LSR miscompile. The test1 function should return '1'.
; It is valid to fold SCEVUnknown into the recurrence because it
; was defined before the loop.
;
; SCEV does not know how to denormalize chained recurrences, so make
; sure they aren't marked as post-inc users.
;
; CHECK-LABEL: IV Users for loop %test1.loop
; CHECK-NO-LCSSA: %sext.us = {0,+,(16777216 + (-16777216 * %sub.us))<nuw><nsw>,+,33554432}<%test1.loop> (post-inc with loop %test1.loop) in %f = ashr i32 %sext.us, 24
define i32 @test1(i1 %cond) {
entry:
%sub.us = select i1 %cond, i32 0, i32 0
br label %test1.loop
test1.loop:
%inc1115.us = phi i32 [ 0, %entry ], [ %inc11.us, %test1.loop ]
%inc11.us = add nsw i32 %inc1115.us, 1
%cmp.us = icmp slt i32 %inc11.us, 2
br i1 %cmp.us, label %test1.loop, label %for.end
for.end:
%tobool.us = icmp eq i32 %inc1115.us, 0
%mul.us = shl i32 %inc1115.us, 24
%sub.cond.us = sub nsw i32 %inc1115.us, %sub.us
%sext.us = mul i32 %mul.us, %sub.cond.us
%f = ashr i32 %sext.us, 24
br label %exit
exit:
ret i32 %f
}
; PR15470: LSR miscompile. The test2 function should return '1'.
Re-enable "[SCEV] Do not fold dominated SCEVUnknown into AddRecExpr start" The patch rL303730 was reverted because test lsr-expand-quadratic.ll failed on many non-X86 configs with this patch. The reason of this is that the patch makes a correctless fix that changes optimizer's behavior for this test. Without the change, LSR was making an overconfident simplification basing on a wrong SCEV. Apparently it did not need the IV analysis to do this. With the change, it chose a different way to simplify (that wasn't so confident), and this way required the IV analysis. Now, following the right execution path, LSR tries to make a transformation relying on IV Users analysis. This analysis is target-dependent due to this code: // LSR is not APInt clean, do not touch integers bigger than 64-bits. // Also avoid creating IVs of non-native types. For example, we don't want a // 64-bit IV in 32-bit code just because the loop has one 64-bit cast. uint64_t Width = SE->getTypeSizeInBits(I->getType()); if (Width > 64 || !DL.isLegalInteger(Width)) return false; To make a proper transformation in this test case, the type i32 needs to be legal for the specified data layout. When the test runs on some non-X86 configuration (e.g. pure ARM 64), opt gets confused by the specified target and does not use it, rejecting the specified data layout as well. Instead, it uses some default layout that does not treat i32 as a legal type (currently the layout that is used when it is not specified does not have legal types at all). As result, the transformation we expect to happen does not happen for this test. This re-enabling patch does not have any source code changes compared to the original patch rL303730. The only difference is that the failing test is moved to X86 directory and now has requirement of running on x86 only to comply with the specified target triple and data layout. Differential Revision: https://reviews.llvm.org/D33543 llvm-svn: 303971
2017-05-26 14:47:04 +08:00
; It is illegal to fold SCEVUnknown (sext.us) into the recurrence
; because it is defined after the loop where this recurrence belongs.
;
; SCEV does not know how to denormalize chained recurrences, so make
; sure they aren't marked as post-inc users.
;
; CHECK-LABEL: IV Users for loop %test2.loop
; CHECK-NO-LCSSA: %sub.cond.us = ((-1 * %sub.us)<nuw><nsw> + {0,+,1}<nuw><nsw><%test2.loop>) (post-inc with loop %test2.loop) in %sext.us = mul i32 %mul.us, %sub.cond.us
define i32 @test2() {
entry:
br label %test2.loop
test2.loop:
%inc1115.us = phi i32 [ 0, %entry ], [ %inc11.us, %test2.loop ]
%inc11.us = add nsw i32 %inc1115.us, 1
%cmp.us = icmp slt i32 %inc11.us, 2
br i1 %cmp.us, label %test2.loop, label %for.end
for.end:
%tobool.us = icmp eq i32 %inc1115.us, 0
%sub.us = select i1 %tobool.us, i32 0, i32 0
%mul.us = shl i32 %inc1115.us, 24
%sub.cond.us = sub nsw i32 %inc1115.us, %sub.us
%sext.us = mul i32 %mul.us, %sub.cond.us
%f = ashr i32 %sext.us, 24
br label %exit
exit:
ret i32 %f
}