llvm-project/polly/lib/Transform/CodePreparation.cpp

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

121 lines
3.7 KiB
C++
Raw Normal View History

//===---- CodePreparation.cpp - Code preparation for Scop Detection -------===//
//
// 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
//
//===----------------------------------------------------------------------===//
//
// The Polly code preparation pass is executed before SCoP detection. Its
// currently only splits the entry block of the SCoP to make room for alloc
// instructions as they are generated during code generation.
//
// XXX: In the future, we should remove the need for this pass entirely and
// instead add this spitting to the code generation pass.
//
//===----------------------------------------------------------------------===//
[Polly][PM][WIP] Polly pass registration Summary: This patch is a first attempt at registering Polly passes with the LLVM tools. Tool plugins are still unsupported, but this registration is usable from the tools if Polly is linked into them (albeit requiring minimal patches to those tools). Registration requires a small amount of machinery (the owning analysis proxies), necessary for injecting ScopAnalysisManager objects into the calling tools. This patch is marked WIP because the registration is incomplete. Parsing manual pipelines is fully supported, but default pass injection into the O3 pipeline is lacking, mostly because there is opportunity for some redesign here, I believe. The first point of order would be insertion points. I think it makes sense to run before the vectorizers. Running Polly Early, however, is weird. Mostly because it actually is the default (which to me is unexpected), and because Polly runs it's own O1 pipeline. Why not instead insert it at an appropriate place somewhere after simplification happend? Running after the loop optimizers seems intuitive, but it also seems wasteful, since multiple consecutive loops might well be a single scop, and we don't need to run for all of them. My second request for comments would be regarding all those smallish helper passes we have, like PollyViewer, PollyPrinter, PollyImportJScop. Right now these are controlled by command line options, deciding whether they should be part of the Polly pipeline. What is your opinion on treating them like real passes, and have the user write an appropriate pipeline if they want to use any of them? Reviewers: grosser, Meinersbur, bollu Reviewed By: grosser Subscribers: llvm-commits, pollydev Tags: #polly Differential Revision: https://reviews.llvm.org/D35458 llvm-svn: 309826
2017-08-02 23:52:25 +08:00
#include "polly/CodePreparation.h"
#include "polly/LinkAllPasses.h"
#include "polly/Support/ScopHelper.h"
#include "llvm/Analysis/DominanceFrontier.h"
#include "llvm/Analysis/LoopInfo.h"
#include "llvm/Analysis/RegionInfo.h"
#include "llvm/Analysis/ScalarEvolution.h"
#include "llvm/InitializePasses.h"
using namespace llvm;
using namespace polly;
namespace {
/// Prepare the IR for the scop detection.
///
class CodePreparation : public FunctionPass {
CodePreparation(const CodePreparation &) = delete;
2015-02-16 14:40:23 +08:00
const CodePreparation &operator=(const CodePreparation &) = delete;
LoopInfo *LI;
ScalarEvolution *SE;
void clear();
public:
static char ID;
explicit CodePreparation() : FunctionPass(ID) {}
~CodePreparation();
/// @name FunctionPass interface.
//@{
2020-07-17 11:12:13 +08:00
void getAnalysisUsage(AnalysisUsage &AU) const override;
void releaseMemory() override;
bool runOnFunction(Function &F) override;
void print(raw_ostream &OS, const Module *) const override;
//@}
};
} // namespace
[Polly][PM][WIP] Polly pass registration Summary: This patch is a first attempt at registering Polly passes with the LLVM tools. Tool plugins are still unsupported, but this registration is usable from the tools if Polly is linked into them (albeit requiring minimal patches to those tools). Registration requires a small amount of machinery (the owning analysis proxies), necessary for injecting ScopAnalysisManager objects into the calling tools. This patch is marked WIP because the registration is incomplete. Parsing manual pipelines is fully supported, but default pass injection into the O3 pipeline is lacking, mostly because there is opportunity for some redesign here, I believe. The first point of order would be insertion points. I think it makes sense to run before the vectorizers. Running Polly Early, however, is weird. Mostly because it actually is the default (which to me is unexpected), and because Polly runs it's own O1 pipeline. Why not instead insert it at an appropriate place somewhere after simplification happend? Running after the loop optimizers seems intuitive, but it also seems wasteful, since multiple consecutive loops might well be a single scop, and we don't need to run for all of them. My second request for comments would be regarding all those smallish helper passes we have, like PollyViewer, PollyPrinter, PollyImportJScop. Right now these are controlled by command line options, deciding whether they should be part of the Polly pipeline. What is your opinion on treating them like real passes, and have the user write an appropriate pipeline if they want to use any of them? Reviewers: grosser, Meinersbur, bollu Reviewed By: grosser Subscribers: llvm-commits, pollydev Tags: #polly Differential Revision: https://reviews.llvm.org/D35458 llvm-svn: 309826
2017-08-02 23:52:25 +08:00
PreservedAnalyses CodePreparationPass::run(Function &F,
FunctionAnalysisManager &FAM) {
// Find first non-alloca instruction. Every basic block has a non-alloca
// instruction, as every well formed basic block has a terminator.
auto &EntryBlock = F.getEntryBlock();
BasicBlock::iterator I = EntryBlock.begin();
while (isa<AllocaInst>(I))
++I;
auto &DT = FAM.getResult<DominatorTreeAnalysis>(F);
auto &LI = FAM.getResult<LoopAnalysis>(F);
// splitBlock updates DT, LI and RI.
splitEntryBlockForAlloca(&EntryBlock, &DT, &LI, nullptr);
PreservedAnalyses PA;
PA.preserve<DominatorTreeAnalysis>();
PA.preserve<LoopAnalysis>();
return PA;
}
void CodePreparation::clear() {}
CodePreparation::~CodePreparation() { clear(); }
void CodePreparation::getAnalysisUsage(AnalysisUsage &AU) const {
AU.addRequired<LoopInfoWrapperPass>();
AU.addRequired<ScalarEvolutionWrapperPass>();
AU.addPreserved<LoopInfoWrapperPass>();
AU.addPreserved<RegionInfoPass>();
AU.addPreserved<DominatorTreeWrapperPass>();
AU.addPreserved<DominanceFrontierWrapperPass>();
}
bool CodePreparation::runOnFunction(Function &F) {
if (skipFunction(F))
return false;
LI = &getAnalysis<LoopInfoWrapperPass>().getLoopInfo();
SE = &getAnalysis<ScalarEvolutionWrapperPass>().getSE();
splitEntryBlockForAlloca(&F.getEntryBlock(), this);
return true;
}
void CodePreparation::releaseMemory() { clear(); }
void CodePreparation::print(raw_ostream &OS, const Module *) const {}
char CodePreparation::ID = 0;
char &polly::CodePreparationID = CodePreparation::ID;
Pass *polly::createCodePreparationPass() { return new CodePreparation(); }
INITIALIZE_PASS_BEGIN(CodePreparation, "polly-prepare",
"Polly - Prepare code for polly", false, false)
INITIALIZE_PASS_DEPENDENCY(LoopInfoWrapperPass)
INITIALIZE_PASS_END(CodePreparation, "polly-prepare",
"Polly - Prepare code for polly", false, false)