2017-01-11 10:43:56 +01:00
|
|
|
//===- LoopAnalysisManager.cpp - Loop analysis management -----------------===//
|
2016-02-25 08:23:08 +01:00
|
|
|
//
|
2019-01-19 09:50:56 +01:00
|
|
|
// 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
|
2016-02-25 08:23:08 +01:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2017-01-11 10:43:56 +01:00
|
|
|
#include "llvm/Analysis/LoopAnalysisManager.h"
|
2016-05-03 23:35:08 +02:00
|
|
|
#include "llvm/Analysis/BasicAliasAnalysis.h"
|
|
|
|
#include "llvm/Analysis/GlobalsModRef.h"
|
|
|
|
#include "llvm/Analysis/LoopInfo.h"
|
2017-11-21 16:45:46 +01:00
|
|
|
#include "llvm/Analysis/MemorySSA.h"
|
2016-05-03 23:35:08 +02:00
|
|
|
#include "llvm/Analysis/ScalarEvolution.h"
|
|
|
|
#include "llvm/Analysis/ScalarEvolutionAliasAnalysis.h"
|
|
|
|
#include "llvm/IR/Dominators.h"
|
Add PassManagerImpl.h to hide implementation details
ClangBuildAnalyzer results show that a lot of time is spent
instantiating AnalysisManager::getResultImpl across the code base:
**** Templates that took longest to instantiate:
50445 ms: llvm::AnalysisManager<llvm::Function>::getResultImpl (412 times, avg 122 ms)
47797 ms: llvm::AnalysisManager<llvm::Function>::getResult<llvm::TargetLibraryAnalysis> (389 times, avg 122 ms)
46894 ms: std::tie<const unsigned long long, const bool> (2452 times, avg 19 ms)
43851 ms: llvm::BumpPtrAllocatorImpl<llvm::MallocAllocator, 4096, 4096>::Allocate (3228 times, avg 13 ms)
33911 ms: std::tie<const unsigned int, const unsigned int, const unsigned int, const unsigned int> (897 times, avg 37 ms)
33854 ms: std::tie<const unsigned long long, const unsigned long long> (1897 times, avg 17 ms)
27886 ms: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string (11156 times, avg 2 ms)
I mentioned this result to @chandlerc, and he suggested this direction.
AnalysisManager is already explicitly instantiated, and getResultImpl
doesn't need to be inlined. Move the definition to an Impl header, and
include that header in files that explicitly instantiate
AnalysisManager. There are only four (real) IR units:
- function
- module
- loop
- cgscc
Looking at a specific transform (ArgumentPromotion.cpp), here are three
compilations before & after this change:
BEFORE:
$ for i in $(seq 3) ; do ./ccit.bat ; done
peak memory: 258.15MB
real: 0m6.297s
peak memory: 257.54MB
real: 0m5.906s
peak memory: 257.47MB
real: 0m6.219s
AFTER:
$ for i in $(seq 3) ; do ./ccit.bat ; done
peak memory: 235.35MB
real: 0m5.454s
peak memory: 234.72MB
real: 0m5.235s
peak memory: 234.39MB
real: 0m5.469s
The 20MB of memory saved seems real, and the time improvement seems like
it is there.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D73817
2020-02-01 01:05:32 +01:00
|
|
|
#include "llvm/IR/PassManagerImpl.h"
|
2016-02-25 08:23:08 +01:00
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
|
2017-11-21 16:45:46 +01:00
|
|
|
namespace llvm {
|
2018-02-28 20:08:52 +01:00
|
|
|
// Explicit template instantiations and specialization definitions for core
|
[PM] Support invalidation of inner analysis managers from a pass over the outer IR unit.
Summary:
This never really got implemented, and was very hard to test before
a lot of the refactoring changes to make things more robust. But now we
can test it thoroughly and cleanly, especially at the CGSCC level.
The core idea is that when an inner analysis manager proxy receives the
invalidation event for the outer IR unit, it needs to walk the inner IR
units and propagate it to the inner analysis manager for each of those
units. For example, each function in the SCC needs to get an
invalidation event when the SCC gets one.
The function / module interaction is somewhat boring here. This really
becomes interesting in the face of analysis-backed IR units. This patch
effectively handles all of the CGSCC layer's needs -- both invalidating
SCC analysis and invalidating function analysis when an SCC gets
invalidated.
However, this second aspect doesn't really handle the
LoopAnalysisManager well at this point. That one will need some change
of design in order to fully integrate, because unlike the call graph,
the entire function behind a LoopAnalysis's results can vanish out from
under us, and we won't even have a cached API to access. I'd like to try
to separate solving the loop problems into a subsequent patch though in
order to keep this more focused so I've adapted them to the API and
updated the tests that immediately fail, but I've not added the level of
testing and validation at that layer that I have at the CGSCC layer.
An important aspect of this change is that the proxy for the
FunctionAnalysisManager at the SCC pass layer doesn't work like the
other proxies for an inner IR unit as it doesn't directly manage the
FunctionAnalysisManager and invalidation or clearing of it. This would
create an ever worsening problem of dual ownership of this
responsibility, split between the module-level FAM proxy and this
SCC-level FAM proxy. Instead, this patch changes the SCC-level FAM proxy
to work in terms of the module-level proxy and defer to it to handle
much of the updates. It only does SCC-specific invalidation. This will
become more important in subsequent patches that support more complex
invalidaiton scenarios.
Reviewers: jlebar
Subscribers: mehdi_amini, mcrosier, mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D27197
llvm-svn: 289317
2016-12-10 07:34:44 +01:00
|
|
|
// template typedefs.
|
2017-01-11 07:23:21 +01:00
|
|
|
template class AllAnalysesOn<Loop>;
|
|
|
|
template class AnalysisManager<Loop, LoopStandardAnalysisResults &>;
|
2016-02-27 11:38:10 +01:00
|
|
|
template class InnerAnalysisManagerProxy<LoopAnalysisManager, Function>;
|
2017-02-07 02:50:48 +01:00
|
|
|
template class OuterAnalysisManagerProxy<FunctionAnalysisManager, Loop,
|
|
|
|
LoopStandardAnalysisResults &>;
|
[PM] Support invalidation of inner analysis managers from a pass over the outer IR unit.
Summary:
This never really got implemented, and was very hard to test before
a lot of the refactoring changes to make things more robust. But now we
can test it thoroughly and cleanly, especially at the CGSCC level.
The core idea is that when an inner analysis manager proxy receives the
invalidation event for the outer IR unit, it needs to walk the inner IR
units and propagate it to the inner analysis manager for each of those
units. For example, each function in the SCC needs to get an
invalidation event when the SCC gets one.
The function / module interaction is somewhat boring here. This really
becomes interesting in the face of analysis-backed IR units. This patch
effectively handles all of the CGSCC layer's needs -- both invalidating
SCC analysis and invalidating function analysis when an SCC gets
invalidated.
However, this second aspect doesn't really handle the
LoopAnalysisManager well at this point. That one will need some change
of design in order to fully integrate, because unlike the call graph,
the entire function behind a LoopAnalysis's results can vanish out from
under us, and we won't even have a cached API to access. I'd like to try
to separate solving the loop problems into a subsequent patch though in
order to keep this more focused so I've adapted them to the API and
updated the tests that immediately fail, but I've not added the level of
testing and validation at that layer that I have at the CGSCC layer.
An important aspect of this change is that the proxy for the
FunctionAnalysisManager at the SCC pass layer doesn't work like the
other proxies for an inner IR unit as it doesn't directly manage the
FunctionAnalysisManager and invalidation or clearing of it. This would
create an ever worsening problem of dual ownership of this
responsibility, split between the module-level FAM proxy and this
SCC-level FAM proxy. Instead, this patch changes the SCC-level FAM proxy
to work in terms of the module-level proxy and defer to it to handle
much of the updates. It only does SCC-specific invalidation. This will
become more important in subsequent patches that support more complex
invalidaiton scenarios.
Reviewers: jlebar
Subscribers: mehdi_amini, mcrosier, mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D27197
llvm-svn: 289317
2016-12-10 07:34:44 +01:00
|
|
|
|
|
|
|
bool LoopAnalysisManagerFunctionProxy::Result::invalidate(
|
|
|
|
Function &F, const PreservedAnalyses &PA,
|
|
|
|
FunctionAnalysisManager::Invalidator &Inv) {
|
2017-01-11 07:23:21 +01:00
|
|
|
// First compute the sequence of IR units covered by this proxy. We will want
|
|
|
|
// to visit this in postorder, but because this is a tree structure we can do
|
2017-01-20 03:41:20 +01:00
|
|
|
// this by building a preorder sequence and walking it backwards. We also
|
|
|
|
// want siblings in forward program order to match the LoopPassManager so we
|
|
|
|
// get the preorder with siblings reversed.
|
|
|
|
SmallVector<Loop *, 4> PreOrderLoops = LI->getLoopsInReverseSiblingPreorder();
|
2017-01-11 07:23:21 +01:00
|
|
|
|
|
|
|
// If this proxy or the loop info is going to be invalidated, we also need
|
|
|
|
// to clear all the keys coming from that analysis. We also completely blow
|
|
|
|
// away the loop analyses if any of the standard analyses provided by the
|
|
|
|
// loop pass manager go away so that loop analyses can freely use these
|
|
|
|
// without worrying about declaring dependencies on them etc.
|
|
|
|
// FIXME: It isn't clear if this is the right tradeoff. We could instead make
|
|
|
|
// loop analyses declare any dependencies on these and use the more general
|
|
|
|
// invalidation logic below to act on that.
|
2016-12-27 09:40:39 +01:00
|
|
|
auto PAC = PA.getChecker<LoopAnalysisManagerFunctionProxy>();
|
2017-11-21 16:45:46 +01:00
|
|
|
bool invalidateMemorySSAAnalysis = false;
|
2019-08-21 19:00:57 +02:00
|
|
|
if (MSSAUsed)
|
2017-11-21 16:45:46 +01:00
|
|
|
invalidateMemorySSAAnalysis = Inv.invalidate<MemorySSAAnalysis>(F, PA);
|
2017-01-11 07:23:21 +01:00
|
|
|
if (!(PAC.preserved() || PAC.preservedSet<AllAnalysesOn<Function>>()) ||
|
|
|
|
Inv.invalidate<AAManager>(F, PA) ||
|
|
|
|
Inv.invalidate<AssumptionAnalysis>(F, PA) ||
|
|
|
|
Inv.invalidate<DominatorTreeAnalysis>(F, PA) ||
|
|
|
|
Inv.invalidate<LoopAnalysis>(F, PA) ||
|
2017-11-21 16:45:46 +01:00
|
|
|
Inv.invalidate<ScalarEvolutionAnalysis>(F, PA) ||
|
|
|
|
invalidateMemorySSAAnalysis) {
|
2017-01-11 07:23:21 +01:00
|
|
|
// Note that the LoopInfo may be stale at this point, however the loop
|
|
|
|
// objects themselves remain the only viable keys that could be in the
|
|
|
|
// analysis manager's cache. So we just walk the keys and forcibly clear
|
|
|
|
// those results. Note that the order doesn't matter here as this will just
|
|
|
|
// directly destroy the results without calling methods on them.
|
2017-10-05 00:02:27 +02:00
|
|
|
for (Loop *L : PreOrderLoops) {
|
|
|
|
// NB! `L` may not be in a good enough state to run Loop::getName.
|
|
|
|
InnerAM->clear(*L, "<possibly invalidated loop>");
|
|
|
|
}
|
2017-01-11 07:23:21 +01:00
|
|
|
|
|
|
|
// We also need to null out the inner AM so that when the object gets
|
|
|
|
// destroyed as invalid we don't try to clear the inner AM again. At that
|
|
|
|
// point we won't be able to reliably walk the loops for this function and
|
|
|
|
// only clear results associated with those loops the way we do here.
|
|
|
|
// FIXME: Making InnerAM null at this point isn't very nice. Most analyses
|
|
|
|
// try to remain valid during invalidation. Maybe we should add an
|
|
|
|
// `IsClean` flag?
|
|
|
|
InnerAM = nullptr;
|
|
|
|
|
|
|
|
// Now return true to indicate this *is* invalid and a fresh proxy result
|
|
|
|
// needs to be built. This is especially important given the null InnerAM.
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Directly check if the relevant set is preserved so we can short circuit
|
|
|
|
// invalidating loops.
|
|
|
|
bool AreLoopAnalysesPreserved =
|
|
|
|
PA.allAnalysesInSetPreserved<AllAnalysesOn<Loop>>();
|
|
|
|
|
|
|
|
// Since we have a valid LoopInfo we can actually leave the cached results in
|
|
|
|
// the analysis manager associated with the Loop keys, but we need to
|
|
|
|
// propagate any necessary invalidation logic into them. We'd like to
|
|
|
|
// invalidate things in roughly the same order as they were put into the
|
|
|
|
// cache and so we walk the preorder list in reverse to form a valid
|
|
|
|
// postorder.
|
|
|
|
for (Loop *L : reverse(PreOrderLoops)) {
|
|
|
|
Optional<PreservedAnalyses> InnerPA;
|
|
|
|
|
|
|
|
// Check to see whether the preserved set needs to be adjusted based on
|
|
|
|
// function-level analysis invalidation triggering deferred invalidation
|
|
|
|
// for this loop.
|
|
|
|
if (auto *OuterProxy =
|
|
|
|
InnerAM->getCachedResult<FunctionAnalysisManagerLoopProxy>(*L))
|
|
|
|
for (const auto &OuterInvalidationPair :
|
|
|
|
OuterProxy->getOuterInvalidations()) {
|
|
|
|
AnalysisKey *OuterAnalysisID = OuterInvalidationPair.first;
|
|
|
|
const auto &InnerAnalysisIDs = OuterInvalidationPair.second;
|
|
|
|
if (Inv.invalidate(OuterAnalysisID, F, PA)) {
|
|
|
|
if (!InnerPA)
|
|
|
|
InnerPA = PA;
|
|
|
|
for (AnalysisKey *InnerAnalysisID : InnerAnalysisIDs)
|
|
|
|
InnerPA->abandon(InnerAnalysisID);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Check if we needed a custom PA set. If so we'll need to run the inner
|
|
|
|
// invalidation.
|
|
|
|
if (InnerPA) {
|
|
|
|
InnerAM->invalidate(*L, *InnerPA);
|
|
|
|
continue;
|
|
|
|
}
|
[PM] Support invalidation of inner analysis managers from a pass over the outer IR unit.
Summary:
This never really got implemented, and was very hard to test before
a lot of the refactoring changes to make things more robust. But now we
can test it thoroughly and cleanly, especially at the CGSCC level.
The core idea is that when an inner analysis manager proxy receives the
invalidation event for the outer IR unit, it needs to walk the inner IR
units and propagate it to the inner analysis manager for each of those
units. For example, each function in the SCC needs to get an
invalidation event when the SCC gets one.
The function / module interaction is somewhat boring here. This really
becomes interesting in the face of analysis-backed IR units. This patch
effectively handles all of the CGSCC layer's needs -- both invalidating
SCC analysis and invalidating function analysis when an SCC gets
invalidated.
However, this second aspect doesn't really handle the
LoopAnalysisManager well at this point. That one will need some change
of design in order to fully integrate, because unlike the call graph,
the entire function behind a LoopAnalysis's results can vanish out from
under us, and we won't even have a cached API to access. I'd like to try
to separate solving the loop problems into a subsequent patch though in
order to keep this more focused so I've adapted them to the API and
updated the tests that immediately fail, but I've not added the level of
testing and validation at that layer that I have at the CGSCC layer.
An important aspect of this change is that the proxy for the
FunctionAnalysisManager at the SCC pass layer doesn't work like the
other proxies for an inner IR unit as it doesn't directly manage the
FunctionAnalysisManager and invalidation or clearing of it. This would
create an ever worsening problem of dual ownership of this
responsibility, split between the module-level FAM proxy and this
SCC-level FAM proxy. Instead, this patch changes the SCC-level FAM proxy
to work in terms of the module-level proxy and defer to it to handle
much of the updates. It only does SCC-specific invalidation. This will
become more important in subsequent patches that support more complex
invalidaiton scenarios.
Reviewers: jlebar
Subscribers: mehdi_amini, mcrosier, mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D27197
llvm-svn: 289317
2016-12-10 07:34:44 +01:00
|
|
|
|
2017-01-11 07:23:21 +01:00
|
|
|
// Otherwise we only need to do invalidation if the original PA set didn't
|
|
|
|
// preserve all Loop analyses.
|
|
|
|
if (!AreLoopAnalysesPreserved)
|
|
|
|
InnerAM->invalidate(*L, PA);
|
|
|
|
}
|
[PM] Support invalidation of inner analysis managers from a pass over the outer IR unit.
Summary:
This never really got implemented, and was very hard to test before
a lot of the refactoring changes to make things more robust. But now we
can test it thoroughly and cleanly, especially at the CGSCC level.
The core idea is that when an inner analysis manager proxy receives the
invalidation event for the outer IR unit, it needs to walk the inner IR
units and propagate it to the inner analysis manager for each of those
units. For example, each function in the SCC needs to get an
invalidation event when the SCC gets one.
The function / module interaction is somewhat boring here. This really
becomes interesting in the face of analysis-backed IR units. This patch
effectively handles all of the CGSCC layer's needs -- both invalidating
SCC analysis and invalidating function analysis when an SCC gets
invalidated.
However, this second aspect doesn't really handle the
LoopAnalysisManager well at this point. That one will need some change
of design in order to fully integrate, because unlike the call graph,
the entire function behind a LoopAnalysis's results can vanish out from
under us, and we won't even have a cached API to access. I'd like to try
to separate solving the loop problems into a subsequent patch though in
order to keep this more focused so I've adapted them to the API and
updated the tests that immediately fail, but I've not added the level of
testing and validation at that layer that I have at the CGSCC layer.
An important aspect of this change is that the proxy for the
FunctionAnalysisManager at the SCC pass layer doesn't work like the
other proxies for an inner IR unit as it doesn't directly manage the
FunctionAnalysisManager and invalidation or clearing of it. This would
create an ever worsening problem of dual ownership of this
responsibility, split between the module-level FAM proxy and this
SCC-level FAM proxy. Instead, this patch changes the SCC-level FAM proxy
to work in terms of the module-level proxy and defer to it to handle
much of the updates. It only does SCC-specific invalidation. This will
become more important in subsequent patches that support more complex
invalidaiton scenarios.
Reviewers: jlebar
Subscribers: mehdi_amini, mcrosier, mzolotukhin, llvm-commits
Differential Revision: https://reviews.llvm.org/D27197
llvm-svn: 289317
2016-12-10 07:34:44 +01:00
|
|
|
|
|
|
|
// Return false to indicate that this result is still a valid proxy.
|
|
|
|
return false;
|
|
|
|
}
|
2017-01-11 07:23:21 +01:00
|
|
|
|
|
|
|
template <>
|
|
|
|
LoopAnalysisManagerFunctionProxy::Result
|
|
|
|
LoopAnalysisManagerFunctionProxy::run(Function &F,
|
|
|
|
FunctionAnalysisManager &AM) {
|
|
|
|
return Result(*InnerAM, AM.getResult<LoopAnalysis>(F));
|
|
|
|
}
|
2016-02-25 08:23:08 +01:00
|
|
|
}
|
2016-05-03 23:35:08 +02:00
|
|
|
|
|
|
|
PreservedAnalyses llvm::getLoopPassPreservedAnalyses() {
|
|
|
|
PreservedAnalyses PA;
|
|
|
|
PA.preserve<DominatorTreeAnalysis>();
|
|
|
|
PA.preserve<LoopAnalysis>();
|
2017-01-11 07:23:21 +01:00
|
|
|
PA.preserve<LoopAnalysisManagerFunctionProxy>();
|
2016-05-03 23:35:08 +02:00
|
|
|
PA.preserve<ScalarEvolutionAnalysis>();
|
2017-11-21 16:45:46 +01:00
|
|
|
// FIXME: What we really want to do here is preserve an AA category, but that
|
2016-05-03 23:35:08 +02:00
|
|
|
// concept doesn't exist yet.
|
2016-12-22 07:59:15 +01:00
|
|
|
PA.preserve<AAManager>();
|
2016-05-03 23:35:08 +02:00
|
|
|
PA.preserve<BasicAA>();
|
|
|
|
PA.preserve<GlobalsAA>();
|
|
|
|
PA.preserve<SCEVAA>();
|
|
|
|
return PA;
|
|
|
|
}
|