From ea5c94b497cfc43f9ec513f721e03aa5c669249a Mon Sep 17 00:00:00 2001 From: Philip Reames Date: Tue, 23 Jul 2019 17:45:11 +0000 Subject: [IndVars] Fix a subtle bug in optimizeLoopExits The original code failed to account for the fact that one exit can have a pointer exit count without all of them having pointer exit counts. This could cause two separate bugs: 1) We might exit the loop early, and leave optimizations undone. This is what triggered the assertion failure in the reported test case. 2) We might optimize one exit, then exit without indicating a change. This could result in an analysis invalidaton bug if no other transform is done by the rest of indvars. Note that the pointer exit counts are a really fragile concept. They show up only when we have a pointer IV w/o a datalayout to provide their size. It's really questionable to me whether the complexity implied is worth it. llvm-svn: 366829 --- llvm/lib/Transforms/Scalar/IndVarSimplify.cpp | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'llvm/lib/Transforms/Scalar') diff --git a/llvm/lib/Transforms/Scalar/IndVarSimplify.cpp b/llvm/lib/Transforms/Scalar/IndVarSimplify.cpp index f9fc698a4a9..41e22b4a212 100644 --- a/llvm/lib/Transforms/Scalar/IndVarSimplify.cpp +++ b/llvm/lib/Transforms/Scalar/IndVarSimplify.cpp @@ -2688,10 +2688,12 @@ bool IndVarSimplify::optimizeLoopExits(Loop *L) { continue; } - // If we end up with a pointer exit count, bail. + // If we end up with a pointer exit count, bail. Note that we can end up + // with a pointer exit count for one exiting block, and not for another in + // the same loop. if (!ExitCount->getType()->isIntegerTy() || !MaxExitCount->getType()->isIntegerTy()) - return false; + continue; Type *WiderType = SE->getWiderType(MaxExitCount->getType(), ExitCount->getType()); -- cgit v1.2.3