2009-05-12 02:17:14 +00:00
|
|
|
//===- IVUsers.cpp - Induction Variable Users -------------------*- C++ -*-===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file implements bookkeeping for "interesting" users of expressions
|
|
|
|
// computed from induction variables.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2012-12-03 16:50:05 +00:00
|
|
|
#include "llvm/ADT/STLExtras.h"
|
2015-07-13 03:28:53 +00:00
|
|
|
#include "llvm/Analysis/AssumptionCache.h"
|
|
|
|
#include "llvm/Analysis/CodeMetrics.h"
|
|
|
|
#include "llvm/Analysis/IVUsers.h"
|
2009-05-12 02:17:14 +00:00
|
|
|
#include "llvm/Analysis/LoopPass.h"
|
|
|
|
#include "llvm/Analysis/ScalarEvolutionExpressions.h"
|
2012-07-13 23:33:05 +00:00
|
|
|
#include "llvm/Analysis/ValueTracking.h"
|
2013-01-02 11:36:10 +00:00
|
|
|
#include "llvm/IR/Constants.h"
|
|
|
|
#include "llvm/IR/DataLayout.h"
|
|
|
|
#include "llvm/IR/DerivedTypes.h"
|
2014-01-13 09:26:24 +00:00
|
|
|
#include "llvm/IR/Dominators.h"
|
2013-01-02 11:36:10 +00:00
|
|
|
#include "llvm/IR/Instructions.h"
|
2015-03-04 18:43:29 +00:00
|
|
|
#include "llvm/IR/Module.h"
|
2013-01-02 11:36:10 +00:00
|
|
|
#include "llvm/IR/Type.h"
|
2009-05-12 02:17:14 +00:00
|
|
|
#include "llvm/Support/Debug.h"
|
|
|
|
#include "llvm/Support/raw_ostream.h"
|
|
|
|
#include <algorithm>
|
|
|
|
using namespace llvm;
|
|
|
|
|
2014-04-22 02:48:03 +00:00
|
|
|
#define DEBUG_TYPE "iv-users"
|
|
|
|
|
2009-05-12 02:17:14 +00:00
|
|
|
char IVUsers::ID = 0;
|
2010-10-12 19:48:12 +00:00
|
|
|
INITIALIZE_PASS_BEGIN(IVUsers, "iv-users",
|
|
|
|
"Induction Variable Users", false, true)
|
2015-07-13 03:28:53 +00:00
|
|
|
INITIALIZE_PASS_DEPENDENCY(AssumptionCacheTracker)
|
2015-01-17 14:16:18 +00:00
|
|
|
INITIALIZE_PASS_DEPENDENCY(LoopInfoWrapperPass)
|
2014-01-13 13:07:17 +00:00
|
|
|
INITIALIZE_PASS_DEPENDENCY(DominatorTreeWrapperPass)
|
[PM] Port ScalarEvolution to the new pass manager.
This change makes ScalarEvolution a stand-alone object and just produces
one from a pass as needed. Making this work well requires making the
object movable, using references instead of overwritten pointers in
a number of places, and other refactorings.
I've also wired it up to the new pass manager and added a RUN line to
a test to exercise it under the new pass manager. This includes basic
printing support much like with other analyses.
But there is a big and somewhat scary change here. Prior to this patch
ScalarEvolution was never *actually* invalidated!!! Re-running the pass
just re-wired up the various other analyses and didn't remove any of the
existing entries in the SCEV caches or clear out anything at all. This
might seem OK as everything in SCEV that can uses ValueHandles to track
updates to the values that serve as SCEV keys. However, this still means
that as we ran SCEV over each function in the module, we kept
accumulating more and more SCEVs into the cache. At the end, we would
have a SCEV cache with every value that we ever needed a SCEV for in the
entire module!!! Yowzers. The releaseMemory routine would dump all of
this, but that isn't realy called during normal runs of the pipeline as
far as I can see.
To make matters worse, there *is* actually a key that we don't update
with value handles -- there is a map keyed off of Loop*s. Because
LoopInfo *does* release its memory from run to run, it is entirely
possible to run SCEV over one function, then over another function, and
then lookup a Loop* from the second function but find an entry inserted
for the first function! Ouch.
To make matters still worse, there are plenty of updates that *don't*
trip a value handle. It seems incredibly unlikely that today GVN or
another pass that invalidates SCEV can update values in *just* such
a way that a subsequent run of SCEV will incorrectly find lookups in
a cache, but it is theoretically possible and would be a nightmare to
debug.
With this refactoring, I've fixed all this by actually destroying and
recreating the ScalarEvolution object from run to run. Technically, this
could increase the amount of malloc traffic we see, but then again it is
also technically correct. ;] I don't actually think we're suffering from
tons of malloc traffic from SCEV because if we were, the fact that we
never clear the memory would seem more likely to have come up as an
actual problem before now. So, I've made the simple fix here. If in fact
there are serious issues with too much allocation and deallocation,
I can work on a clever fix that preserves the allocations (while
clearing the data) between each run, but I'd prefer to do that kind of
optimization with a test case / benchmark that shows why we need such
cleverness (and that can test that we actually make it faster). It's
possible that this will make some things faster by making the SCEV
caches have higher locality (due to being significantly smaller) so
until there is a clear benchmark, I think the simple change is best.
Differential Revision: http://reviews.llvm.org/D12063
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@245193 91177308-0d34-0410-b5e6-96231b3b80d8
2015-08-17 02:08:17 +00:00
|
|
|
INITIALIZE_PASS_DEPENDENCY(ScalarEvolutionWrapperPass)
|
2010-10-12 19:48:12 +00:00
|
|
|
INITIALIZE_PASS_END(IVUsers, "iv-users",
|
|
|
|
"Induction Variable Users", false, true)
|
2009-05-12 02:17:14 +00:00
|
|
|
|
|
|
|
Pass *llvm::createIVUsersPass() {
|
|
|
|
return new IVUsers();
|
|
|
|
}
|
|
|
|
|
2010-09-01 01:45:53 +00:00
|
|
|
/// isInteresting - Test whether the given expression is "interesting" when
|
|
|
|
/// used by the given expression, within the context of analyzing the
|
|
|
|
/// given loop.
|
|
|
|
static bool isInteresting(const SCEV *S, const Instruction *I, const Loop *L,
|
2011-07-01 22:05:19 +00:00
|
|
|
ScalarEvolution *SE, LoopInfo *LI) {
|
2010-04-07 22:27:08 +00:00
|
|
|
// An addrec is interesting if it's affine or if it has an interesting start.
|
|
|
|
if (const SCEVAddRecExpr *AR = dyn_cast<SCEVAddRecExpr>(S)) {
|
2011-07-01 22:05:19 +00:00
|
|
|
// Keep things simple. Don't touch loop-variant strides unless they're
|
|
|
|
// only used outside the loop and we can simplify them.
|
2010-04-09 01:22:56 +00:00
|
|
|
if (AR->getLoop() == L)
|
2011-07-01 22:05:19 +00:00
|
|
|
return AR->isAffine() ||
|
|
|
|
(!L->contains(I) &&
|
|
|
|
SE->getSCEVAtScope(AR, LI->getLoopFor(I->getParent())) != AR);
|
2010-09-01 01:45:53 +00:00
|
|
|
// Otherwise recurse to see if the start value is interesting, and that
|
|
|
|
// the step value is not interesting, since we don't yet know how to
|
|
|
|
// do effective SCEV expansions for addrecs with interesting steps.
|
2011-07-01 22:05:19 +00:00
|
|
|
return isInteresting(AR->getStart(), I, L, SE, LI) &&
|
|
|
|
!isInteresting(AR->getStepRecurrence(*SE), I, L, SE, LI);
|
2009-05-12 02:17:14 +00:00
|
|
|
}
|
|
|
|
|
2010-08-17 22:50:37 +00:00
|
|
|
// An add is interesting if exactly one of its operands is interesting.
|
2010-04-07 22:27:08 +00:00
|
|
|
if (const SCEVAddExpr *Add = dyn_cast<SCEVAddExpr>(S)) {
|
2010-09-01 01:45:53 +00:00
|
|
|
bool AnyInterestingYet = false;
|
2010-04-07 22:27:08 +00:00
|
|
|
for (SCEVAddExpr::op_iterator OI = Add->op_begin(), OE = Add->op_end();
|
|
|
|
OI != OE; ++OI)
|
2011-07-01 22:05:19 +00:00
|
|
|
if (isInteresting(*OI, I, L, SE, LI)) {
|
2010-09-01 01:45:53 +00:00
|
|
|
if (AnyInterestingYet)
|
|
|
|
return false;
|
|
|
|
AnyInterestingYet = true;
|
|
|
|
}
|
|
|
|
return AnyInterestingYet;
|
2010-04-07 22:27:08 +00:00
|
|
|
}
|
2009-05-12 02:17:14 +00:00
|
|
|
|
2010-04-07 22:27:08 +00:00
|
|
|
// Nothing else is interesting here.
|
2010-09-01 01:45:53 +00:00
|
|
|
return false;
|
2009-05-12 02:17:14 +00:00
|
|
|
}
|
|
|
|
|
2012-03-20 21:24:40 +00:00
|
|
|
/// Return true if all loop headers that dominate this block are in simplified
|
|
|
|
/// form.
|
|
|
|
static bool isSimplifiedLoopNest(BasicBlock *BB, const DominatorTree *DT,
|
|
|
|
const LoopInfo *LI,
|
2014-08-21 05:55:13 +00:00
|
|
|
SmallPtrSetImpl<Loop*> &SimpleLoopNests) {
|
2014-04-15 04:59:12 +00:00
|
|
|
Loop *NearestLoop = nullptr;
|
2012-03-20 21:24:40 +00:00
|
|
|
for (DomTreeNode *Rung = DT->getNode(BB);
|
2012-03-16 03:16:56 +00:00
|
|
|
Rung; Rung = Rung->getIDom()) {
|
2012-03-20 21:24:40 +00:00
|
|
|
BasicBlock *DomBB = Rung->getBlock();
|
|
|
|
Loop *DomLoop = LI->getLoopFor(DomBB);
|
|
|
|
if (DomLoop && DomLoop->getHeader() == DomBB) {
|
|
|
|
// If the domtree walk reaches a loop with no preheader, return false.
|
2012-03-16 03:16:56 +00:00
|
|
|
if (!DomLoop->isLoopSimplifyForm())
|
|
|
|
return false;
|
2012-03-20 21:24:40 +00:00
|
|
|
// If we have already checked this loop nest, stop checking.
|
|
|
|
if (SimpleLoopNests.count(DomLoop))
|
|
|
|
break;
|
|
|
|
// If we have not already checked this loop nest, remember the loop
|
|
|
|
// header nearest to BB. The nearest loop may not contain BB.
|
|
|
|
if (!NearestLoop)
|
|
|
|
NearestLoop = DomLoop;
|
2012-03-16 03:16:56 +00:00
|
|
|
}
|
|
|
|
}
|
2012-03-20 21:24:40 +00:00
|
|
|
if (NearestLoop)
|
|
|
|
SimpleLoopNests.insert(NearestLoop);
|
2012-03-16 03:16:56 +00:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2012-03-22 17:47:33 +00:00
|
|
|
/// AddUsersImpl - Inspect the specified instruction. If it is a
|
2010-09-01 01:45:53 +00:00
|
|
|
/// reducible SCEV, recursively add its users to the IVUsesByStride set and
|
|
|
|
/// return true. Otherwise, return false.
|
2012-03-22 17:47:33 +00:00
|
|
|
bool IVUsers::AddUsersImpl(Instruction *I,
|
2014-08-21 05:55:13 +00:00
|
|
|
SmallPtrSetImpl<Loop*> &SimpleLoopNests) {
|
2015-03-10 02:37:25 +00:00
|
|
|
const DataLayout &DL = I->getModule()->getDataLayout();
|
|
|
|
|
2012-01-06 21:41:55 +00:00
|
|
|
// Add this IV user to the Processed set before returning false to ensure that
|
|
|
|
// all IV users are members of the set. See IVUsers::isIVUserOrOperand.
|
2014-11-19 07:49:26 +00:00
|
|
|
if (!Processed.insert(I).second)
|
2012-01-06 21:41:55 +00:00
|
|
|
return true; // Instruction already handled.
|
|
|
|
|
2010-09-01 01:45:53 +00:00
|
|
|
if (!SE->isSCEVable(I->getType()))
|
|
|
|
return false; // Void and FP expressions cannot be reduced.
|
2009-05-12 02:17:14 +00:00
|
|
|
|
2012-07-13 23:33:05 +00:00
|
|
|
// IVUsers is used by LSR which assumes that all SCEV expressions are safe to
|
|
|
|
// pass to SCEVExpander. Expressions are not safe to expand if they represent
|
|
|
|
// operations that are not safe to speculate, namely integer division.
|
2015-03-10 02:37:25 +00:00
|
|
|
if (!isa<PHINode>(I) && !isSafeToSpeculativelyExecute(I))
|
2012-07-13 23:33:05 +00:00
|
|
|
return false;
|
|
|
|
|
2009-05-12 02:17:14 +00:00
|
|
|
// LSR is not APInt clean, do not touch integers bigger than 64-bits.
|
2011-03-18 16:50:32 +00:00
|
|
|
// 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());
|
2015-03-10 02:37:25 +00:00
|
|
|
if (Width > 64 || !DL.isLegalInteger(Width))
|
2009-05-12 02:17:14 +00:00
|
|
|
return false;
|
|
|
|
|
2015-07-13 03:28:53 +00:00
|
|
|
// Don't attempt to promote ephemeral values to indvars. They will be removed
|
|
|
|
// later anyway.
|
|
|
|
if (EphValues.count(I))
|
|
|
|
return false;
|
|
|
|
|
2010-09-01 01:45:53 +00:00
|
|
|
// Get the symbolic expression for this instruction.
|
|
|
|
const SCEV *ISE = SE->getSCEV(I);
|
2009-05-12 02:17:14 +00:00
|
|
|
|
2010-09-01 01:45:53 +00:00
|
|
|
// If we've come to an uninteresting expression, stop the traversal and
|
|
|
|
// call this a user.
|
2011-07-01 22:05:19 +00:00
|
|
|
if (!isInteresting(ISE, I, L, SE, LI))
|
2010-09-01 01:45:53 +00:00
|
|
|
return false;
|
2009-11-19 02:05:44 +00:00
|
|
|
|
2010-09-01 01:45:53 +00:00
|
|
|
SmallPtrSet<Instruction *, 4> UniqueUsers;
|
2014-03-09 03:16:01 +00:00
|
|
|
for (Use &U : I->uses()) {
|
|
|
|
Instruction *User = cast<Instruction>(U.getUser());
|
2014-11-19 07:49:26 +00:00
|
|
|
if (!UniqueUsers.insert(User).second)
|
2010-09-01 01:45:53 +00:00
|
|
|
continue;
|
|
|
|
|
|
|
|
// Do not infinitely recurse on PHI nodes.
|
|
|
|
if (isa<PHINode>(User) && Processed.count(User))
|
|
|
|
continue;
|
|
|
|
|
2012-03-16 03:16:56 +00:00
|
|
|
// Only consider IVUsers that are dominated by simplified loop
|
|
|
|
// headers. Otherwise, SCEVExpander will crash.
|
2012-03-20 21:24:44 +00:00
|
|
|
BasicBlock *UseBB = User->getParent();
|
|
|
|
// A phi's use is live out of its predecessor block.
|
|
|
|
if (PHINode *PHI = dyn_cast<PHINode>(User)) {
|
2014-03-09 03:16:01 +00:00
|
|
|
unsigned OperandNo = U.getOperandNo();
|
2012-03-20 21:24:44 +00:00
|
|
|
unsigned ValNo = PHINode::getIncomingValueNumForOperand(OperandNo);
|
|
|
|
UseBB = PHI->getIncomingBlock(ValNo);
|
|
|
|
}
|
|
|
|
if (!isSimplifiedLoopNest(UseBB, DT, LI, SimpleLoopNests))
|
2012-03-20 21:24:40 +00:00
|
|
|
return false;
|
2012-03-16 03:16:56 +00:00
|
|
|
|
2010-09-01 01:45:53 +00:00
|
|
|
// Descend recursively, but not into PHI nodes outside the current loop.
|
|
|
|
// It's important to see the entire expression outside the loop to get
|
|
|
|
// choices that depend on addressing mode use right, although we won't
|
|
|
|
// consider references outside the loop in all cases.
|
|
|
|
// If User is already in Processed, we don't want to recurse into it again,
|
|
|
|
// but do want to record a second reference in the same instruction.
|
|
|
|
bool AddUserToIVUsers = false;
|
2012-03-20 21:24:40 +00:00
|
|
|
if (LI->getLoopFor(User->getParent()) != L) {
|
2010-09-01 01:45:53 +00:00
|
|
|
if (isa<PHINode>(User) || Processed.count(User) ||
|
2012-03-22 17:47:33 +00:00
|
|
|
!AddUsersImpl(User, SimpleLoopNests)) {
|
2010-09-01 01:45:53 +00:00
|
|
|
DEBUG(dbgs() << "FOUND USER in other loop: " << *User << '\n'
|
|
|
|
<< " OF SCEV: " << *ISE << '\n');
|
|
|
|
AddUserToIVUsers = true;
|
2009-05-12 02:17:14 +00:00
|
|
|
}
|
2012-03-22 17:47:33 +00:00
|
|
|
} else if (Processed.count(User) || !AddUsersImpl(User, SimpleLoopNests)) {
|
2010-09-01 01:45:53 +00:00
|
|
|
DEBUG(dbgs() << "FOUND USER: " << *User << '\n'
|
|
|
|
<< " OF SCEV: " << *ISE << '\n');
|
|
|
|
AddUserToIVUsers = true;
|
|
|
|
}
|
2009-05-12 02:17:14 +00:00
|
|
|
|
2010-09-01 01:45:53 +00:00
|
|
|
if (AddUserToIVUsers) {
|
|
|
|
// Okay, we found a user that we cannot reduce.
|
2014-03-12 21:31:05 +00:00
|
|
|
IVStrideUse &NewUse = AddUser(User, I);
|
2011-05-27 18:42:33 +00:00
|
|
|
// Autodetect the post-inc loop set, populating NewUse.PostIncLoops.
|
|
|
|
// The regular return value here is discarded; instead of recording
|
|
|
|
// it, we just recompute it when we need it.
|
2014-03-12 21:31:05 +00:00
|
|
|
const SCEV *OriginalISE = ISE;
|
2010-09-01 01:45:53 +00:00
|
|
|
ISE = TransformForPostIncUse(NormalizeAutodetect,
|
|
|
|
ISE, User, I,
|
|
|
|
NewUse.PostIncLoops,
|
|
|
|
*SE, *DT);
|
2014-03-12 21:31:05 +00:00
|
|
|
|
|
|
|
// PostIncNormalization effectively simplifies the expression under
|
|
|
|
// pre-increment assumptions. Those assumptions (no wrapping) might not
|
|
|
|
// hold for the post-inc value. Catch such cases by making sure the
|
|
|
|
// transformation is invertible.
|
|
|
|
if (OriginalISE != ISE) {
|
|
|
|
const SCEV *DenormalizedISE =
|
|
|
|
TransformForPostIncUse(Denormalize, ISE, User, I,
|
|
|
|
NewUse.PostIncLoops, *SE, *DT);
|
|
|
|
|
|
|
|
// If we normalized the expression, but denormalization doesn't give the
|
|
|
|
// original one, discard this user.
|
|
|
|
if (OriginalISE != DenormalizedISE) {
|
|
|
|
DEBUG(dbgs() << " DISCARDING (NORMALIZATION ISN'T INVERTIBLE): "
|
|
|
|
<< *ISE << '\n');
|
|
|
|
IVUses.pop_back();
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
2011-10-13 17:06:38 +00:00
|
|
|
DEBUG(if (SE->getSCEV(I) != ISE)
|
|
|
|
dbgs() << " NORMALIZED TO: " << *ISE << '\n');
|
2009-05-12 02:17:14 +00:00
|
|
|
}
|
2010-09-01 01:45:53 +00:00
|
|
|
}
|
|
|
|
return true;
|
2009-05-12 02:17:14 +00:00
|
|
|
}
|
|
|
|
|
2012-03-22 17:47:33 +00:00
|
|
|
bool IVUsers::AddUsersIfInteresting(Instruction *I) {
|
|
|
|
// SCEVExpander can only handle users that are dominated by simplified loop
|
|
|
|
// entries. Keep track of all loops that are only dominated by other simple
|
|
|
|
// loops so we don't traverse the domtree for each user.
|
|
|
|
SmallPtrSet<Loop*,16> SimpleLoopNests;
|
|
|
|
|
|
|
|
return AddUsersImpl(I, SimpleLoopNests);
|
|
|
|
}
|
|
|
|
|
2011-06-21 15:43:52 +00:00
|
|
|
IVStrideUse &IVUsers::AddUser(Instruction *User, Value *Operand) {
|
|
|
|
IVUses.push_back(new IVStrideUse(this, User, Operand));
|
2010-09-01 01:45:53 +00:00
|
|
|
return IVUses.back();
|
2009-11-12 07:35:05 +00:00
|
|
|
}
|
|
|
|
|
2009-05-12 02:17:14 +00:00
|
|
|
IVUsers::IVUsers()
|
2010-10-19 17:21:58 +00:00
|
|
|
: LoopPass(ID) {
|
|
|
|
initializeIVUsersPass(*PassRegistry::getPassRegistry());
|
2009-05-12 02:17:14 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void IVUsers::getAnalysisUsage(AnalysisUsage &AU) const {
|
2015-07-13 03:28:53 +00:00
|
|
|
AU.addRequired<AssumptionCacheTracker>();
|
2015-01-17 14:16:18 +00:00
|
|
|
AU.addRequired<LoopInfoWrapperPass>();
|
2014-01-13 13:07:17 +00:00
|
|
|
AU.addRequired<DominatorTreeWrapperPass>();
|
[PM] Port ScalarEvolution to the new pass manager.
This change makes ScalarEvolution a stand-alone object and just produces
one from a pass as needed. Making this work well requires making the
object movable, using references instead of overwritten pointers in
a number of places, and other refactorings.
I've also wired it up to the new pass manager and added a RUN line to
a test to exercise it under the new pass manager. This includes basic
printing support much like with other analyses.
But there is a big and somewhat scary change here. Prior to this patch
ScalarEvolution was never *actually* invalidated!!! Re-running the pass
just re-wired up the various other analyses and didn't remove any of the
existing entries in the SCEV caches or clear out anything at all. This
might seem OK as everything in SCEV that can uses ValueHandles to track
updates to the values that serve as SCEV keys. However, this still means
that as we ran SCEV over each function in the module, we kept
accumulating more and more SCEVs into the cache. At the end, we would
have a SCEV cache with every value that we ever needed a SCEV for in the
entire module!!! Yowzers. The releaseMemory routine would dump all of
this, but that isn't realy called during normal runs of the pipeline as
far as I can see.
To make matters worse, there *is* actually a key that we don't update
with value handles -- there is a map keyed off of Loop*s. Because
LoopInfo *does* release its memory from run to run, it is entirely
possible to run SCEV over one function, then over another function, and
then lookup a Loop* from the second function but find an entry inserted
for the first function! Ouch.
To make matters still worse, there are plenty of updates that *don't*
trip a value handle. It seems incredibly unlikely that today GVN or
another pass that invalidates SCEV can update values in *just* such
a way that a subsequent run of SCEV will incorrectly find lookups in
a cache, but it is theoretically possible and would be a nightmare to
debug.
With this refactoring, I've fixed all this by actually destroying and
recreating the ScalarEvolution object from run to run. Technically, this
could increase the amount of malloc traffic we see, but then again it is
also technically correct. ;] I don't actually think we're suffering from
tons of malloc traffic from SCEV because if we were, the fact that we
never clear the memory would seem more likely to have come up as an
actual problem before now. So, I've made the simple fix here. If in fact
there are serious issues with too much allocation and deallocation,
I can work on a clever fix that preserves the allocations (while
clearing the data) between each run, but I'd prefer to do that kind of
optimization with a test case / benchmark that shows why we need such
cleverness (and that can test that we actually make it faster). It's
possible that this will make some things faster by making the SCEV
caches have higher locality (due to being significantly smaller) so
until there is a clear benchmark, I think the simple change is best.
Differential Revision: http://reviews.llvm.org/D12063
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@245193 91177308-0d34-0410-b5e6-96231b3b80d8
2015-08-17 02:08:17 +00:00
|
|
|
AU.addRequired<ScalarEvolutionWrapperPass>();
|
2009-05-12 02:17:14 +00:00
|
|
|
AU.setPreservesAll();
|
|
|
|
}
|
|
|
|
|
|
|
|
bool IVUsers::runOnLoop(Loop *l, LPPassManager &LPM) {
|
|
|
|
|
|
|
|
L = l;
|
2015-07-13 03:28:53 +00:00
|
|
|
AC = &getAnalysis<AssumptionCacheTracker>().getAssumptionCache(
|
|
|
|
*L->getHeader()->getParent());
|
2015-01-17 14:16:18 +00:00
|
|
|
LI = &getAnalysis<LoopInfoWrapperPass>().getLoopInfo();
|
2014-01-13 13:07:17 +00:00
|
|
|
DT = &getAnalysis<DominatorTreeWrapperPass>().getDomTree();
|
[PM] Port ScalarEvolution to the new pass manager.
This change makes ScalarEvolution a stand-alone object and just produces
one from a pass as needed. Making this work well requires making the
object movable, using references instead of overwritten pointers in
a number of places, and other refactorings.
I've also wired it up to the new pass manager and added a RUN line to
a test to exercise it under the new pass manager. This includes basic
printing support much like with other analyses.
But there is a big and somewhat scary change here. Prior to this patch
ScalarEvolution was never *actually* invalidated!!! Re-running the pass
just re-wired up the various other analyses and didn't remove any of the
existing entries in the SCEV caches or clear out anything at all. This
might seem OK as everything in SCEV that can uses ValueHandles to track
updates to the values that serve as SCEV keys. However, this still means
that as we ran SCEV over each function in the module, we kept
accumulating more and more SCEVs into the cache. At the end, we would
have a SCEV cache with every value that we ever needed a SCEV for in the
entire module!!! Yowzers. The releaseMemory routine would dump all of
this, but that isn't realy called during normal runs of the pipeline as
far as I can see.
To make matters worse, there *is* actually a key that we don't update
with value handles -- there is a map keyed off of Loop*s. Because
LoopInfo *does* release its memory from run to run, it is entirely
possible to run SCEV over one function, then over another function, and
then lookup a Loop* from the second function but find an entry inserted
for the first function! Ouch.
To make matters still worse, there are plenty of updates that *don't*
trip a value handle. It seems incredibly unlikely that today GVN or
another pass that invalidates SCEV can update values in *just* such
a way that a subsequent run of SCEV will incorrectly find lookups in
a cache, but it is theoretically possible and would be a nightmare to
debug.
With this refactoring, I've fixed all this by actually destroying and
recreating the ScalarEvolution object from run to run. Technically, this
could increase the amount of malloc traffic we see, but then again it is
also technically correct. ;] I don't actually think we're suffering from
tons of malloc traffic from SCEV because if we were, the fact that we
never clear the memory would seem more likely to have come up as an
actual problem before now. So, I've made the simple fix here. If in fact
there are serious issues with too much allocation and deallocation,
I can work on a clever fix that preserves the allocations (while
clearing the data) between each run, but I'd prefer to do that kind of
optimization with a test case / benchmark that shows why we need such
cleverness (and that can test that we actually make it faster). It's
possible that this will make some things faster by making the SCEV
caches have higher locality (due to being significantly smaller) so
until there is a clear benchmark, I think the simple change is best.
Differential Revision: http://reviews.llvm.org/D12063
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@245193 91177308-0d34-0410-b5e6-96231b3b80d8
2015-08-17 02:08:17 +00:00
|
|
|
SE = &getAnalysis<ScalarEvolutionWrapperPass>().getSE();
|
2009-05-12 02:17:14 +00:00
|
|
|
|
2015-07-13 03:28:53 +00:00
|
|
|
// Collect ephemeral values so that AddUsersIfInteresting skips them.
|
|
|
|
EphValues.clear();
|
|
|
|
CodeMetrics::collectEphemeralValues(L, AC, EphValues);
|
|
|
|
|
2009-05-12 02:17:14 +00:00
|
|
|
// Find all uses of induction variables in this loop, and categorize
|
|
|
|
// them by stride. Start by finding all of the PHI nodes in the header for
|
|
|
|
// this loop. If they are induction variables, inspect their uses.
|
|
|
|
for (BasicBlock::iterator I = L->getHeader()->begin(); isa<PHINode>(I); ++I)
|
Analysis: Remove implicit ilist iterator conversions
Remove implicit ilist iterator conversions from LLVMAnalysis.
I came across something really scary in `llvm::isKnownNotFullPoison()`
which relied on `Instruction::getNextNode()` being completely broken
(not surprising, but scary nevertheless). This function is documented
(and coded to) return `nullptr` when it gets to the sentinel, but with
an `ilist_half_node` as a sentinel, the sentinel check looks into some
other memory and we don't recognize we've hit the end.
Rooting out these scary cases is the reason I'm removing the implicit
conversions before doing anything else with `ilist`; I'm not at all
surprised that clients rely on badness.
I found another scary case -- this time, not relying on badness, just
bad (but I guess getting lucky so far) -- in
`ObjectSizeOffsetEvaluator::compute_()`. Here, we save out the
insertion point, do some things, and then restore it. Previously, we
let the iterator auto-convert to `Instruction*`, and then set it back
using the `Instruction*` version:
Instruction *PrevInsertPoint = Builder.GetInsertPoint();
/* Logic that may change insert point */
if (PrevInsertPoint)
Builder.SetInsertPoint(PrevInsertPoint);
The check for `PrevInsertPoint` doesn't protect correctly against bad
accesses. If the insertion point has been set to the end of a basic
block (i.e., `SetInsertPoint(SomeBB)`), then `GetInsertPoint()` returns
an iterator pointing at the list sentinel. The version of
`SetInsertPoint()` that's getting called will then call
`PrevInsertPoint->getParent()`, which explodes horribly. The only
reason this hasn't blown up is that it's fairly unlikely the builder is
adding to the end of the block; usually, we're adding instructions
somewhere before the terminator.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@249925 91177308-0d34-0410-b5e6-96231b3b80d8
2015-10-10 00:53:03 +00:00
|
|
|
(void)AddUsersIfInteresting(&*I);
|
2009-05-12 02:17:14 +00:00
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
void IVUsers::print(raw_ostream &OS, const Module *M) const {
|
|
|
|
OS << "IV Users for loop ";
|
2014-01-09 02:29:41 +00:00
|
|
|
L->getHeader()->printAsOperand(OS, false);
|
2009-05-12 02:17:14 +00:00
|
|
|
if (SE->hasLoopInvariantBackedgeTakenCount(L)) {
|
|
|
|
OS << " with backedge-taken count "
|
|
|
|
<< *SE->getBackedgeTakenCount(L);
|
|
|
|
}
|
|
|
|
OS << ":\n";
|
|
|
|
|
2010-02-12 10:34:29 +00:00
|
|
|
for (ilist<IVStrideUse>::const_iterator UI = IVUses.begin(),
|
|
|
|
E = IVUses.end(); UI != E; ++UI) {
|
|
|
|
OS << " ";
|
2014-01-09 02:29:41 +00:00
|
|
|
UI->getOperandValToReplace()->printAsOperand(OS, false);
|
2010-04-19 21:48:58 +00:00
|
|
|
OS << " = " << *getReplacementExpr(*UI);
|
2010-04-07 22:27:08 +00:00
|
|
|
for (PostIncLoopSet::const_iterator
|
|
|
|
I = UI->PostIncLoops.begin(),
|
|
|
|
E = UI->PostIncLoops.end(); I != E; ++I) {
|
|
|
|
OS << " (post-inc with loop ";
|
2014-01-09 02:29:41 +00:00
|
|
|
(*I)->getHeader()->printAsOperand(OS, false);
|
2010-04-07 22:27:08 +00:00
|
|
|
OS << ")";
|
|
|
|
}
|
2010-02-12 10:34:29 +00:00
|
|
|
OS << " in ";
|
2014-06-21 02:43:02 +00:00
|
|
|
if (UI->getUser())
|
|
|
|
UI->getUser()->print(OS);
|
|
|
|
else
|
|
|
|
OS << "Printing <null> User";
|
2010-02-12 10:34:29 +00:00
|
|
|
OS << '\n';
|
2009-05-12 02:17:14 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-09-12 05:06:18 +00:00
|
|
|
#if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
|
2016-01-29 20:50:44 +00:00
|
|
|
LLVM_DUMP_METHOD void IVUsers::dump() const {
|
2009-12-23 20:20:46 +00:00
|
|
|
print(dbgs());
|
2009-05-12 02:17:14 +00:00
|
|
|
}
|
2012-09-06 19:55:56 +00:00
|
|
|
#endif
|
2009-05-12 02:17:14 +00:00
|
|
|
|
|
|
|
void IVUsers::releaseMemory() {
|
2009-12-17 09:39:49 +00:00
|
|
|
Processed.clear();
|
2009-12-18 00:06:20 +00:00
|
|
|
IVUses.clear();
|
2009-05-12 02:17:14 +00:00
|
|
|
}
|
|
|
|
|
2010-04-19 21:48:58 +00:00
|
|
|
/// getReplacementExpr - Return a SCEV expression which computes the
|
|
|
|
/// value of the OperandValToReplace.
|
|
|
|
const SCEV *IVUsers::getReplacementExpr(const IVStrideUse &IU) const {
|
|
|
|
return SE->getSCEV(IU.getOperandValToReplace());
|
|
|
|
}
|
|
|
|
|
|
|
|
/// getExpr - Return the expression for the use.
|
|
|
|
const SCEV *IVUsers::getExpr(const IVStrideUse &IU) const {
|
|
|
|
return
|
|
|
|
TransformForPostIncUse(Normalize, getReplacementExpr(IU),
|
|
|
|
IU.getUser(), IU.getOperandValToReplace(),
|
|
|
|
const_cast<PostIncLoopSet &>(IU.getPostIncLoops()),
|
|
|
|
*SE, *DT);
|
|
|
|
}
|
|
|
|
|
2010-04-07 22:27:08 +00:00
|
|
|
static const SCEVAddRecExpr *findAddRecForLoop(const SCEV *S, const Loop *L) {
|
|
|
|
if (const SCEVAddRecExpr *AR = dyn_cast<SCEVAddRecExpr>(S)) {
|
|
|
|
if (AR->getLoop() == L)
|
|
|
|
return AR;
|
|
|
|
return findAddRecForLoop(AR->getStart(), L);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (const SCEVAddExpr *Add = dyn_cast<SCEVAddExpr>(S)) {
|
|
|
|
for (SCEVAddExpr::op_iterator I = Add->op_begin(), E = Add->op_end();
|
|
|
|
I != E; ++I)
|
|
|
|
if (const SCEVAddRecExpr *AR = findAddRecForLoop(*I, L))
|
|
|
|
return AR;
|
2014-04-15 04:59:12 +00:00
|
|
|
return nullptr;
|
2010-04-07 22:27:08 +00:00
|
|
|
}
|
|
|
|
|
2014-04-15 04:59:12 +00:00
|
|
|
return nullptr;
|
2010-04-07 22:27:08 +00:00
|
|
|
}
|
|
|
|
|
2010-04-19 21:48:58 +00:00
|
|
|
const SCEV *IVUsers::getStride(const IVStrideUse &IU, const Loop *L) const {
|
|
|
|
if (const SCEVAddRecExpr *AR = findAddRecForLoop(getExpr(IU), L))
|
|
|
|
return AR->getStepRecurrence(*SE);
|
2014-04-15 04:59:12 +00:00
|
|
|
return nullptr;
|
2010-04-07 22:27:08 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void IVStrideUse::transformToPostInc(const Loop *L) {
|
|
|
|
PostIncLoops.insert(L);
|
|
|
|
}
|
|
|
|
|
2009-05-12 02:17:14 +00:00
|
|
|
void IVStrideUse::deleted() {
|
|
|
|
// Remove this user from the list.
|
2012-01-06 21:41:55 +00:00
|
|
|
Parent->Processed.erase(this->getUser());
|
2010-02-12 10:34:29 +00:00
|
|
|
Parent->IVUses.erase(this);
|
2009-05-12 02:17:14 +00:00
|
|
|
// this now dangles!
|
|
|
|
}
|