llvm-project/llvm/lib/Analysis/LoopPass.cpp

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

385 lines
13 KiB
C++
Raw Normal View History

2007-02-22 16:56:17 +08:00
//===- LoopPass.cpp - Loop Pass and Loop Pass Manager ---------------------===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
2007-02-22 16:56:17 +08:00
//
//===----------------------------------------------------------------------===//
//
// This file implements LoopPass and LPPassManager. All loop optimization
// and transformation passes are derived from LoopPass. LPPassManager is
// responsible for managing LoopPasses.
//
//===----------------------------------------------------------------------===//
#include "llvm/Analysis/LoopPass.h"
#include "llvm/Analysis/LoopAnalysisManager.h"
#include "llvm/IR/Dominators.h"
#include "llvm/IR/IRPrintingPasses.h"
#include "llvm/IR/LLVMContext.h"
#include "llvm/IR/OptBisect.h"
#include "llvm/IR/PassManager.h"
#include "llvm/IR/PassTimingInfo.h"
#include "llvm/InitializePasses.h"
#include "llvm/Support/Debug.h"
#include "llvm/Support/TimeProfiler.h"
#include "llvm/Support/Timer.h"
#include "llvm/Support/raw_ostream.h"
2007-02-22 16:56:17 +08:00
using namespace llvm;
[Modules] Make Support/Debug.h modular. This requires it to not change behavior based on other files defining DEBUG_TYPE, which means it cannot define DEBUG_TYPE at all. This is actually better IMO as it forces folks to define relevant DEBUG_TYPEs for their files. However, it requires all files that currently use DEBUG(...) to define a DEBUG_TYPE if they don't already. I've updated all such files in LLVM and will do the same for other upstream projects. This still leaves one important change in how LLVM uses the DEBUG_TYPE macro going forward: we need to only define the macro *after* header files have been #include-ed. Previously, this wasn't possible because Debug.h required the macro to be pre-defined. This commit removes that. By defining DEBUG_TYPE after the includes two things are fixed: - Header files that need to provide a DEBUG_TYPE for some inline code can do so by defining the macro before their inline code and undef-ing it afterward so the macro does not escape. - We no longer have rampant ODR violations due to including headers with different DEBUG_TYPE definitions. This may be mostly an academic violation today, but with modules these types of violations are easy to check for and potentially very relevant. Where necessary to suppor headers with DEBUG_TYPE, I have moved the definitions below the includes in this commit. I plan to move the rest of the DEBUG_TYPE macros in LLVM in subsequent commits; this one is big enough. The comments in Debug.h, which were hilariously out of date already, have been updated to reflect the recommended practice going forward. llvm-svn: 206822
2014-04-22 06:55:11 +08:00
#define DEBUG_TYPE "loop-pass-manager"
namespace {
/// PrintLoopPass - Print a Function corresponding to a Loop.
///
class PrintLoopPassWrapper : public LoopPass {
[PM] Rewrite the loop pass manager to use a worklist and augmented run arguments much like the CGSCC pass manager. This is a major redesign following the pattern establish for the CGSCC layer to support updates to the set of loops during the traversal of the loop nest and to support invalidation of analyses. An additional significant burden in the loop PM is that so many passes require access to a large number of function analyses. Manually ensuring these are cached, available, and preserved has been a long-standing burden in LLVM even with the help of the automatic scheduling in the old pass manager. And it made the new pass manager extremely unweildy. With this design, we can package the common analyses up while in a function pass and make them immediately available to all the loop passes. While in some cases this is unnecessary, I think the simplicity afforded is worth it. This does not (yet) address loop simplified form or LCSSA form, but those are the next things on my radar and I have a clear plan for them. While the patch is very large, most of it is either mechanically updating loop passes to the new API or the new testing for the loop PM. The code for it is reasonably compact. I have not yet updated all of the loop passes to correctly leverage the update mechanisms demonstrated in the unittests. I'll do that in follow-up patches along with improved FileCheck tests for those passes that ensure things work in more realistic scenarios. In many cases, there isn't much we can do with these until the loop simplified form and LCSSA form are in place. Differential Revision: https://reviews.llvm.org/D28292 llvm-svn: 291651
2017-01-11 14:23:21 +08:00
raw_ostream &OS;
std::string Banner;
public:
static char ID;
[PM] Rewrite the loop pass manager to use a worklist and augmented run arguments much like the CGSCC pass manager. This is a major redesign following the pattern establish for the CGSCC layer to support updates to the set of loops during the traversal of the loop nest and to support invalidation of analyses. An additional significant burden in the loop PM is that so many passes require access to a large number of function analyses. Manually ensuring these are cached, available, and preserved has been a long-standing burden in LLVM even with the help of the automatic scheduling in the old pass manager. And it made the new pass manager extremely unweildy. With this design, we can package the common analyses up while in a function pass and make them immediately available to all the loop passes. While in some cases this is unnecessary, I think the simplicity afforded is worth it. This does not (yet) address loop simplified form or LCSSA form, but those are the next things on my radar and I have a clear plan for them. While the patch is very large, most of it is either mechanically updating loop passes to the new API or the new testing for the loop PM. The code for it is reasonably compact. I have not yet updated all of the loop passes to correctly leverage the update mechanisms demonstrated in the unittests. I'll do that in follow-up patches along with improved FileCheck tests for those passes that ensure things work in more realistic scenarios. In many cases, there isn't much we can do with these until the loop simplified form and LCSSA form are in place. Differential Revision: https://reviews.llvm.org/D28292 llvm-svn: 291651
2017-01-11 14:23:21 +08:00
PrintLoopPassWrapper() : LoopPass(ID), OS(dbgs()) {}
PrintLoopPassWrapper(raw_ostream &OS, const std::string &Banner)
[PM] Rewrite the loop pass manager to use a worklist and augmented run arguments much like the CGSCC pass manager. This is a major redesign following the pattern establish for the CGSCC layer to support updates to the set of loops during the traversal of the loop nest and to support invalidation of analyses. An additional significant burden in the loop PM is that so many passes require access to a large number of function analyses. Manually ensuring these are cached, available, and preserved has been a long-standing burden in LLVM even with the help of the automatic scheduling in the old pass manager. And it made the new pass manager extremely unweildy. With this design, we can package the common analyses up while in a function pass and make them immediately available to all the loop passes. While in some cases this is unnecessary, I think the simplicity afforded is worth it. This does not (yet) address loop simplified form or LCSSA form, but those are the next things on my radar and I have a clear plan for them. While the patch is very large, most of it is either mechanically updating loop passes to the new API or the new testing for the loop PM. The code for it is reasonably compact. I have not yet updated all of the loop passes to correctly leverage the update mechanisms demonstrated in the unittests. I'll do that in follow-up patches along with improved FileCheck tests for those passes that ensure things work in more realistic scenarios. In many cases, there isn't much we can do with these until the loop simplified form and LCSSA form are in place. Differential Revision: https://reviews.llvm.org/D28292 llvm-svn: 291651
2017-01-11 14:23:21 +08:00
: LoopPass(ID), OS(OS), Banner(Banner) {}
void getAnalysisUsage(AnalysisUsage &AU) const override {
AU.setPreservesAll();
}
bool runOnLoop(Loop *L, LPPassManager &) override {
[PM/Unswitch] Teach SimpleLoopUnswitch to do non-trivial unswitching, making it no longer even remotely simple. The pass will now be more of a "full loop unswitching" pass rather than anything substantively simpler than any other approach. I plan to rename it accordingly once the dust settles. The key ideas of the new loop unswitcher are carried over for non-trivial unswitching: 1) Fully unswitch a branch or switch instruction from inside of a loop to outside of it. 2) Update the CFG and IR. This avoids needing to "remember" the unswitched branches as well as avoiding excessively cloning and reliance on complex parts of simplify-cfg to cleanup the cfg. 3) Update the analyses (where we can) rather than just blowing them away or relying on something else updating them. Sadly, #3 is somewhat compromised here as the dominator tree updates were too complex for me to want to reason about. I will need to make another attempt to do this now that we have a nice dynamic update API for dominators. However, we do adhere to #3 w.r.t. LoopInfo. This approach also adds an important principls specific to non-trivial unswitching: not *all* of the loop will be duplicated when unswitching. This fact allows us to compute the cost in terms of how much *duplicate* code is inserted rather than just on raw size. Unswitching conditions which essentialy partition loops will work regardless of the total loop size. Some remaining issues that I will be addressing in subsequent commits: - Handling unstructured control flow. - Unswitching 'switch' cases instead of just branches. - Moving to the dynamic update API for dominators. Some high-level, interesting limitationsV that folks might want to push on as follow-ups but that I don't have any immediate plans around: - We could be much more clever about not cloning things that will be deleted. In fact, we should be able to delete *nothing* and do a minimal number of clones. - There are many more interesting selection criteria for which branch to unswitch that we might want to look at. One that I'm interested in particularly are a set of conditions which all exit the loop and which can be merged into a single unswitched test of them. Differential revision: https://reviews.llvm.org/D34200 llvm-svn: 318549
2017-11-18 03:58:36 +08:00
auto BBI = llvm::find_if(L->blocks(), [](BasicBlock *BB) { return BB; });
if (BBI != L->blocks().end() &&
isFunctionInPrintList((*BBI)->getParent()->getName())) {
[PM] Rewrite the loop pass manager to use a worklist and augmented run arguments much like the CGSCC pass manager. This is a major redesign following the pattern establish for the CGSCC layer to support updates to the set of loops during the traversal of the loop nest and to support invalidation of analyses. An additional significant burden in the loop PM is that so many passes require access to a large number of function analyses. Manually ensuring these are cached, available, and preserved has been a long-standing burden in LLVM even with the help of the automatic scheduling in the old pass manager. And it made the new pass manager extremely unweildy. With this design, we can package the common analyses up while in a function pass and make them immediately available to all the loop passes. While in some cases this is unnecessary, I think the simplicity afforded is worth it. This does not (yet) address loop simplified form or LCSSA form, but those are the next things on my radar and I have a clear plan for them. While the patch is very large, most of it is either mechanically updating loop passes to the new API or the new testing for the loop PM. The code for it is reasonably compact. I have not yet updated all of the loop passes to correctly leverage the update mechanisms demonstrated in the unittests. I'll do that in follow-up patches along with improved FileCheck tests for those passes that ensure things work in more realistic scenarios. In many cases, there isn't much we can do with these until the loop simplified form and LCSSA form are in place. Differential Revision: https://reviews.llvm.org/D28292 llvm-svn: 291651
2017-01-11 14:23:21 +08:00
printLoop(*L, OS, Banner);
}
return false;
}
StringRef getPassName() const override { return "Print Loop IR"; }
};
char PrintLoopPassWrapper::ID = 0;
}
2007-02-22 16:56:17 +08:00
//===----------------------------------------------------------------------===//
// LPPassManager
//
2007-05-03 09:11:54 +08:00
char LPPassManager::ID = 0;
2007-02-22 16:56:17 +08:00
LPPassManager::LPPassManager()
: FunctionPass(ID), PMDataManager() {
LI = nullptr;
CurrentLoop = nullptr;
}
// Insert loop into loop nest (LoopInfo) and loop queue (LQ).
void LPPassManager::addLoop(Loop &L) {
if (!L.getParentLoop()) {
// This is the top level loop.
LQ.push_front(&L);
return;
}
// Insert L into the loop queue after the parent loop.
for (auto I = LQ.begin(), E = LQ.end(); I != E; ++I) {
if (*I == L.getParentLoop()) {
// deque does not support insert after.
++I;
LQ.insert(I, 1, &L);
return;
}
}
}
// Recurse through all subloops and all loops into LQ.
static void addLoopIntoQueue(Loop *L, std::deque<Loop *> &LQ) {
LQ.push_back(L);
for (Loop *I : reverse(*L))
addLoopIntoQueue(I, LQ);
}
/// Pass Manager itself does not invalidate any analysis info.
void LPPassManager::getAnalysisUsage(AnalysisUsage &Info) const {
2011-08-04 07:45:50 +08:00
// LPPassManager needs LoopInfo. In the long term LoopInfo class will
// become part of LPPassManager.
Info.addRequired<LoopInfoWrapperPass>();
Info.addRequired<DominatorTreeWrapperPass>();
Info.setPreservesAll();
}
void LPPassManager::markLoopAsDeleted(Loop &L) {
assert((&L == CurrentLoop || CurrentLoop->contains(&L)) &&
"Must not delete loop outside the current loop tree!");
// If this loop appears elsewhere within the queue, we also need to remove it
// there. However, we have to be careful to not remove the back of the queue
// as that is assumed to match the current loop.
assert(LQ.back() == CurrentLoop && "Loop queue back isn't the current loop!");
LQ.erase(std::remove(LQ.begin(), LQ.end(), &L), LQ.end());
if (&L == CurrentLoop) {
CurrentLoopDeleted = true;
// Add this loop back onto the back of the queue to preserve our invariants.
LQ.push_back(&L);
}
}
2007-02-22 16:56:17 +08:00
/// run - Execute all of the passes scheduled for execution. Keep track of
/// whether any of the passes modifies the function, and if so, return true.
bool LPPassManager::runOnFunction(Function &F) {
auto &LIWP = getAnalysis<LoopInfoWrapperPass>();
LI = &LIWP.getLoopInfo();
Module &M = *F.getParent();
#if 0
DominatorTree *DT = &getAnalysis<DominatorTreeWrapperPass>().getDomTree();
#endif
2007-02-22 16:56:17 +08:00
bool Changed = false;
// Collect inherited analysis from Module level pass manager.
populateInheritedAnalysis(TPM->activeStack);
// Populate the loop queue in reverse program order. There is no clear need to
// process sibling loops in either forward or reverse order. There may be some
// advantage in deleting uses in a later loop before optimizing the
// definitions in an earlier loop. If we find a clear reason to process in
// forward order, then a forward variant of LoopPassManager should be created.
//
// Note that LoopInfo::iterator visits loops in reverse program
// order. Here, reverse_iterator gives us a forward order, and the LoopQueue
// reverses the order a third time by popping from the back.
for (Loop *L : reverse(*LI))
addLoopIntoQueue(L, LQ);
if (LQ.empty()) // No loops, skip calling finalizers
return false;
// Initialization
for (Loop *L : LQ) {
2011-08-04 07:45:50 +08:00
for (unsigned Index = 0; Index < getNumContainedPasses(); ++Index) {
LoopPass *P = getContainedPass(Index);
Changed |= P->doInitialization(L, *this);
}
}
2007-02-22 16:56:17 +08:00
// Walk Loops
unsigned InstrCount, FunctionSize = 0;
StringMap<std::pair<unsigned, unsigned>> FunctionToInstrCount;
bool EmitICRemark = M.shouldEmitInstrCountChangedRemark();
// Collect the initial size of the module and the function we're looking at.
if (EmitICRemark) {
InstrCount = initSizeRemarkInfo(M, FunctionToInstrCount);
FunctionSize = F.getInstructionCount();
}
while (!LQ.empty()) {
CurrentLoopDeleted = false;
CurrentLoop = LQ.back();
2009-09-28 07:52:07 +08:00
// Run all passes on the current Loop.
2011-08-04 07:45:50 +08:00
for (unsigned Index = 0; Index < getNumContainedPasses(); ++Index) {
LoopPass *P = getContainedPass(Index);
llvm::TimeTraceScope LoopPassScope("RunLoopPass", P->getPassName());
dumpPassInfo(P, EXECUTION_MSG, ON_LOOP_MSG,
2010-04-01 00:06:22 +08:00
CurrentLoop->getHeader()->getName());
dumpRequiredSet(P);
2007-02-22 16:56:17 +08:00
initializeAnalysisImpl(P);
bool LocalChanged = false;
{
PassManagerPrettyStackEntry X(P, *CurrentLoop->getHeader());
TimeRegion PassTimer(getPassTimer(P));
LocalChanged = P->runOnLoop(CurrentLoop, *this);
Changed |= LocalChanged;
if (EmitICRemark) {
unsigned NewSize = F.getInstructionCount();
// Update the size of the function, emit a remark, and update the
// size of the module.
if (NewSize != FunctionSize) {
int64_t Delta = static_cast<int64_t>(NewSize) -
static_cast<int64_t>(FunctionSize);
emitInstrCountChangedRemark(P, M, Delta, InstrCount,
FunctionToInstrCount, &F);
InstrCount = static_cast<int64_t>(InstrCount) + Delta;
FunctionSize = NewSize;
}
}
}
2007-02-22 16:56:17 +08:00
if (LocalChanged)
dumpPassInfo(P, MODIFICATION_MSG, ON_LOOP_MSG,
CurrentLoopDeleted ? "<deleted loop>"
: CurrentLoop->getName());
dumpPreservedSet(P);
2007-07-20 02:02:32 +08:00
if (!CurrentLoopDeleted) {
// Manually check that this loop is still healthy. This is done
// instead of relying on LoopInfo::verifyLoop since LoopInfo
// is a function pass and it's really expensive to verify every
// loop in the function every time. That level of checking can be
// enabled with the -verify-loop-info option.
{
TimeRegion PassTimer(getPassTimer(&LIWP));
CurrentLoop->verifyLoop();
}
// Here we apply same reasoning as in the above case. Only difference
// is that LPPassManager might run passes which do not require LCSSA
// form (LoopPassPrinter for example). We should skip verification for
// such passes.
// FIXME: Loop-sink currently break LCSSA. Fix it and reenable the
// verification!
#if 0
if (mustPreserveAnalysisID(LCSSAVerificationPass::ID))
assert(CurrentLoop->isRecursivelyLCSSAForm(*DT, *LI));
#endif
// Then call the regular verifyAnalysis functions.
verifyPreservedAnalysis(P);
F.getContext().yield();
}
2007-02-22 16:56:17 +08:00
removeNotPreservedAnalysis(P);
recordAvailableAnalysis(P);
removeDeadPasses(P,
CurrentLoopDeleted ? "<deleted>"
: CurrentLoop->getHeader()->getName(),
ON_LOOP_MSG);
if (CurrentLoopDeleted)
// Do not run other passes on this loop.
break;
2007-02-22 16:56:17 +08:00
}
2011-08-04 07:45:50 +08:00
// If the loop was deleted, release all the loop passes. This frees up
// some memory, and avoids trouble with the pass manager trying to call
// verifyAnalysis on them.
if (CurrentLoopDeleted) {
2011-08-04 07:45:50 +08:00
for (unsigned Index = 0; Index < getNumContainedPasses(); ++Index) {
Pass *P = getContainedPass(Index);
freePass(P, "<deleted>", ON_LOOP_MSG);
}
}
// Pop the loop from queue after running all passes.
LQ.pop_back();
2007-02-22 16:56:17 +08:00
}
2011-08-04 07:45:50 +08:00
// Finalization
for (unsigned Index = 0; Index < getNumContainedPasses(); ++Index) {
LoopPass *P = getContainedPass(Index);
Changed |= P->doFinalization();
}
2007-02-22 16:56:17 +08:00
return Changed;
}
/// Print passes managed by this manager
void LPPassManager::dumpPassStructure(unsigned Offset) {
errs().indent(Offset*2) << "Loop Pass Manager\n";
for (unsigned Index = 0; Index < getNumContainedPasses(); ++Index) {
Pass *P = getContainedPass(Index);
P->dumpPassStructure(Offset + 1);
dumpLastUses(P, Offset+1);
}
}
2007-02-22 16:56:17 +08:00
//===----------------------------------------------------------------------===//
// LoopPass
Pass *LoopPass::createPrinterPass(raw_ostream &O,
const std::string &Banner) const {
return new PrintLoopPassWrapper(O, Banner);
}
// Check if this pass is suitable for the current LPPassManager, if
// available. This pass P is not suitable for a LPPassManager if P
// is not preserving higher level analysis info used by other
// LPPassManager passes. In such case, pop LPPassManager from the
// stack. This will force assignPassManager() to create new
// LPPassManger as expected.
void LoopPass::preparePassManager(PMStack &PMS) {
2011-08-04 07:45:50 +08:00
// Find LPPassManager
while (!PMS.empty() &&
PMS.top()->getPassManagerType() > PMT_LoopPassManager)
PMS.pop();
// If this pass is destroying high level information that is used
// by other passes that are managed by LPM then do not insert
// this pass in current LPM. Use new LPPassManager.
if (PMS.top()->getPassManagerType() == PMT_LoopPassManager &&
2011-08-04 07:45:50 +08:00
!PMS.top()->preserveHigherLevelAnalysis(this))
PMS.pop();
}
/// Assign pass manager to manage this pass.
void LoopPass::assignPassManager(PMStack &PMS,
PassManagerType PreferredType) {
2011-08-04 07:45:50 +08:00
// Find LPPassManager
while (!PMS.empty() &&
PMS.top()->getPassManagerType() > PMT_LoopPassManager)
PMS.pop();
LPPassManager *LPPM;
if (PMS.top()->getPassManagerType() == PMT_LoopPassManager)
LPPM = (LPPassManager*)PMS.top();
else {
2011-08-04 07:45:50 +08:00
// Create new Loop Pass Manager if it does not exist.
assert (!PMS.empty() && "Unable to create Loop Pass Manager");
PMDataManager *PMD = PMS.top();
// [1] Create new Loop Pass Manager
LPPM = new LPPassManager();
LPPM->populateInheritedAnalysis(PMS);
// [2] Set up new manager's top level manager
PMTopLevelManager *TPM = PMD->getTopLevelManager();
TPM->addIndirectPassManager(LPPM);
// [3] Assign manager to manage this new manager. This may create
// and push new managers into PMS
Pass *P = LPPM->getAsPass();
TPM->schedulePass(P);
// [4] Push new manager into PMS
PMS.push(LPPM);
}
LPPM->add(this);
}
static std::string getDescription(const Loop &L) {
return "loop";
}
bool LoopPass::skipLoop(const Loop *L) const {
const Function *F = L->getHeader()->getParent();
if (!F)
return false;
// Check the opt bisect limit.
OptPassGate &Gate = F->getContext().getOptPassGate();
if (Gate.isEnabled() && !Gate.shouldRunPass(this, getDescription(*L)))
return true;
// Check for the OptimizeNone attribute.
if (F->hasOptNone()) {
// FIXME: Report this to dbgs() only once per function.
LLVM_DEBUG(dbgs() << "Skipping pass '" << getPassName() << "' in function "
<< F->getName() << "\n");
// FIXME: Delete loop from pass manager's queue?
return true;
}
return false;
}
LCSSAVerificationPass::LCSSAVerificationPass() : FunctionPass(ID) {
initializeLCSSAVerificationPassPass(*PassRegistry::getPassRegistry());
}
char LCSSAVerificationPass::ID = 0;
INITIALIZE_PASS(LCSSAVerificationPass, "lcssa-verification", "LCSSA Verifier",
false, false)