maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/unittests/Analysis/CGSCCPassManagerTest.cpp

1087 lines
40 KiB
C++
Raw Normal View History

[PM] Add a unittest for the CGSCC pass manager in the new pass manager system. Previously, this was only being tested with larger integration tests. That makes it hard to isolated specific issues with it, and makes the APIs themselves less well tested. Add a unittest based around the same patterns used for testing the general pass manager. llvm-svn: 261624
2016-02-23 18:02:02 +08:00
//===- CGSCCPassManagerTest.cpp -------------------------------------------===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
#include "llvm/Analysis/CGSCCPassManager.h"
#include "llvm/Analysis/LazyCallGraph.h"
#include "llvm/AsmParser/Parser.h"
#include "llvm/IR/Function.h"
#include "llvm/IR/InstIterator.h"
#include "llvm/IR/LLVMContext.h"
#include "llvm/IR/Module.h"
#include "llvm/IR/PassManager.h"
#include "llvm/Support/SourceMgr.h"
#include "gtest/gtest.h"
using namespace llvm;
namespace {
[PM] Change the static object whose address is used to uniquely identify analyses to have a common type which is enforced rather than using a char object and a `void *` type when used as an identifier. This has a number of advantages. First, it at least helps some of the confusion raised in Justin Lebar's code review of why `void *` was being used everywhere by having a stronger type that connects to documentation about this. However, perhaps more importantly, it addresses a serious issue where the alignment of these pointer-like identifiers was unknown. This made it hard to use them in pointer-like data structures. We were already dodging this in dangerous ways to create the "all analyses" entry. In a subsequent patch I attempted to use these with TinyPtrVector and things fell apart in a very bad way. And it isn't just a compile time or type system issue. Worse than that, the actual alignment of these pointer-like opaque identifiers wasn't guaranteed to be a useful alignment as they were just characters. This change introduces a type to use as the "key" object whose address forms the opaque identifier. This both forces the objects to have proper alignment, and provides type checking that we get it right everywhere. It also makes the types somewhat less mysterious than `void *`. We could go one step further and introduce a truly opaque pointer-like type to return from the `ID()` static function rather than returning `AnalysisKey *`, but that didn't seem to be a clear win so this is just the initial change to get to a reliably typed and aligned object serving is a key for all the analyses. Thanks to Richard Smith and Justin Lebar for helping pick plausible names and avoid making this refactoring many times. =] And thanks to Sean for the super fast review! While here, I've tried to move away from the "PassID" nomenclature entirely as it wasn't really helping and is overloaded with old pass manager constructs. Now we have IDs for analyses, and key objects whose address can be used as IDs. Where possible and clear I've shortened this to just "ID". In a few places I kept "AnalysisID" to make it clear what was being identified. Differential Revision: https://reviews.llvm.org/D27031 llvm-svn: 287783
2016-11-24 01:53:26 +08:00
class TestModuleAnalysis : public AnalysisInfoMixin<TestModuleAnalysis> {
[PM] Add a unittest for the CGSCC pass manager in the new pass manager system. Previously, this was only being tested with larger integration tests. That makes it hard to isolated specific issues with it, and makes the APIs themselves less well tested. Add a unittest based around the same patterns used for testing the general pass manager. llvm-svn: 261624
2016-02-23 18:02:02 +08:00
public:
struct Result {
Result(int Count) : FunctionCount(Count) {}
int FunctionCount;
};
TestModuleAnalysis(int &Runs) : Runs(Runs) {}
[PM] Make the AnalysisManager parameter to run methods a reference. This was originally a pointer to support pass managers which didn't use AnalysisManagers. However, that doesn't realistically come up much and the complexity of supporting it doesn't really make sense. In fact, *many* parts of the pass manager were just assuming the pointer was never null already. This at least makes it much more explicit and clear. llvm-svn: 263219
2016-03-11 19:05:24 +08:00
Result run(Module &M, ModuleAnalysisManager &AM) {
[PM] Add a unittest for the CGSCC pass manager in the new pass manager system. Previously, this was only being tested with larger integration tests. That makes it hard to isolated specific issues with it, and makes the APIs themselves less well tested. Add a unittest based around the same patterns used for testing the general pass manager. llvm-svn: 261624
2016-02-23 18:02:02 +08:00
++Runs;
return Result(M.size());
}
private:
[PM] Change the static object whose address is used to uniquely identify analyses to have a common type which is enforced rather than using a char object and a `void *` type when used as an identifier. This has a number of advantages. First, it at least helps some of the confusion raised in Justin Lebar's code review of why `void *` was being used everywhere by having a stronger type that connects to documentation about this. However, perhaps more importantly, it addresses a serious issue where the alignment of these pointer-like identifiers was unknown. This made it hard to use them in pointer-like data structures. We were already dodging this in dangerous ways to create the "all analyses" entry. In a subsequent patch I attempted to use these with TinyPtrVector and things fell apart in a very bad way. And it isn't just a compile time or type system issue. Worse than that, the actual alignment of these pointer-like opaque identifiers wasn't guaranteed to be a useful alignment as they were just characters. This change introduces a type to use as the "key" object whose address forms the opaque identifier. This both forces the objects to have proper alignment, and provides type checking that we get it right everywhere. It also makes the types somewhat less mysterious than `void *`. We could go one step further and introduce a truly opaque pointer-like type to return from the `ID()` static function rather than returning `AnalysisKey *`, but that didn't seem to be a clear win so this is just the initial change to get to a reliably typed and aligned object serving is a key for all the analyses. Thanks to Richard Smith and Justin Lebar for helping pick plausible names and avoid making this refactoring many times. =] And thanks to Sean for the super fast review! While here, I've tried to move away from the "PassID" nomenclature entirely as it wasn't really helping and is overloaded with old pass manager constructs. Now we have IDs for analyses, and key objects whose address can be used as IDs. Where possible and clear I've shortened this to just "ID". In a few places I kept "AnalysisID" to make it clear what was being identified. Differential Revision: https://reviews.llvm.org/D27031 llvm-svn: 287783
2016-11-24 01:53:26 +08:00
friend AnalysisInfoMixin<TestModuleAnalysis>;
static AnalysisKey Key;
[PM] Add a unittest for the CGSCC pass manager in the new pass manager system. Previously, this was only being tested with larger integration tests. That makes it hard to isolated specific issues with it, and makes the APIs themselves less well tested. Add a unittest based around the same patterns used for testing the general pass manager. llvm-svn: 261624
2016-02-23 18:02:02 +08:00
int &Runs;
};
[PM] Change the static object whose address is used to uniquely identify analyses to have a common type which is enforced rather than using a char object and a `void *` type when used as an identifier. This has a number of advantages. First, it at least helps some of the confusion raised in Justin Lebar's code review of why `void *` was being used everywhere by having a stronger type that connects to documentation about this. However, perhaps more importantly, it addresses a serious issue where the alignment of these pointer-like identifiers was unknown. This made it hard to use them in pointer-like data structures. We were already dodging this in dangerous ways to create the "all analyses" entry. In a subsequent patch I attempted to use these with TinyPtrVector and things fell apart in a very bad way. And it isn't just a compile time or type system issue. Worse than that, the actual alignment of these pointer-like opaque identifiers wasn't guaranteed to be a useful alignment as they were just characters. This change introduces a type to use as the "key" object whose address forms the opaque identifier. This both forces the objects to have proper alignment, and provides type checking that we get it right everywhere. It also makes the types somewhat less mysterious than `void *`. We could go one step further and introduce a truly opaque pointer-like type to return from the `ID()` static function rather than returning `AnalysisKey *`, but that didn't seem to be a clear win so this is just the initial change to get to a reliably typed and aligned object serving is a key for all the analyses. Thanks to Richard Smith and Justin Lebar for helping pick plausible names and avoid making this refactoring many times. =] And thanks to Sean for the super fast review! While here, I've tried to move away from the "PassID" nomenclature entirely as it wasn't really helping and is overloaded with old pass manager constructs. Now we have IDs for analyses, and key objects whose address can be used as IDs. Where possible and clear I've shortened this to just "ID". In a few places I kept "AnalysisID" to make it clear what was being identified. Differential Revision: https://reviews.llvm.org/D27031 llvm-svn: 287783
2016-11-24 01:53:26 +08:00
AnalysisKey TestModuleAnalysis::Key;
[PM] Add a unittest for the CGSCC pass manager in the new pass manager system. Previously, this was only being tested with larger integration tests. That makes it hard to isolated specific issues with it, and makes the APIs themselves less well tested. Add a unittest based around the same patterns used for testing the general pass manager. llvm-svn: 261624
2016-02-23 18:02:02 +08:00
[PM] Change the static object whose address is used to uniquely identify analyses to have a common type which is enforced rather than using a char object and a `void *` type when used as an identifier. This has a number of advantages. First, it at least helps some of the confusion raised in Justin Lebar's code review of why `void *` was being used everywhere by having a stronger type that connects to documentation about this. However, perhaps more importantly, it addresses a serious issue where the alignment of these pointer-like identifiers was unknown. This made it hard to use them in pointer-like data structures. We were already dodging this in dangerous ways to create the "all analyses" entry. In a subsequent patch I attempted to use these with TinyPtrVector and things fell apart in a very bad way. And it isn't just a compile time or type system issue. Worse than that, the actual alignment of these pointer-like opaque identifiers wasn't guaranteed to be a useful alignment as they were just characters. This change introduces a type to use as the "key" object whose address forms the opaque identifier. This both forces the objects to have proper alignment, and provides type checking that we get it right everywhere. It also makes the types somewhat less mysterious than `void *`. We could go one step further and introduce a truly opaque pointer-like type to return from the `ID()` static function rather than returning `AnalysisKey *`, but that didn't seem to be a clear win so this is just the initial change to get to a reliably typed and aligned object serving is a key for all the analyses. Thanks to Richard Smith and Justin Lebar for helping pick plausible names and avoid making this refactoring many times. =] And thanks to Sean for the super fast review! While here, I've tried to move away from the "PassID" nomenclature entirely as it wasn't really helping and is overloaded with old pass manager constructs. Now we have IDs for analyses, and key objects whose address can be used as IDs. Where possible and clear I've shortened this to just "ID". In a few places I kept "AnalysisID" to make it clear what was being identified. Differential Revision: https://reviews.llvm.org/D27031 llvm-svn: 287783
2016-11-24 01:53:26 +08:00
class TestSCCAnalysis : public AnalysisInfoMixin<TestSCCAnalysis> {
[PM] Add a unittest for the CGSCC pass manager in the new pass manager system. Previously, this was only being tested with larger integration tests. That makes it hard to isolated specific issues with it, and makes the APIs themselves less well tested. Add a unittest based around the same patterns used for testing the general pass manager. llvm-svn: 261624
2016-02-23 18:02:02 +08:00
public:
struct Result {
Result(int Count) : FunctionCount(Count) {}
int FunctionCount;
};
TestSCCAnalysis(int &Runs) : Runs(Runs) {}
[PM] Introduce basic update capabilities to the new PM's CGSCC pass manager, including both plumbing and logic to handle function pass updates. There are three fundamentally tied changes here: 1) Plumbing *some* mechanism for updating the CGSCC pass manager as the CG changes while passes are running. 2) Changing the CGSCC pass manager infrastructure to have support for the underlying graph to mutate mid-pass run. 3) Actually updating the CG after function passes run. I can separate them if necessary, but I think its really useful to have them together as the needs of #3 drove #2, and that in turn drove #1. The plumbing technique is to extend the "run" method signature with extra arguments. We provide the call graph that intrinsically is available as it is the basis of the pass manager's IR units, and an output parameter that records the results of updating the call graph during an SCC passes's run. Note that "...UpdateResult" isn't a *great* name here... suggestions very welcome. I tried a pretty frustrating number of different data structures and such for the innards of the update result. Every other one failed for one reason or another. Sometimes I just couldn't keep the layers of complexity right in my head. The thing that really worked was to just directly provide access to the underlying structures used to walk the call graph so that their updates could be informed by the *particular* nature of the change to the graph. The technique for how to make the pass management infrastructure cope with mutating graphs was also something that took a really, really large number of iterations to get to a place where I was happy. Here are some of the considerations that drove the design: - We operate at three levels within the infrastructure: RefSCC, SCC, and Node. In each case, we are working bottom up and so we want to continue to iterate on the "lowest" node as the graph changes. Look at how we iterate over nodes in an SCC running function passes as those function passes mutate the CG. We continue to iterate on the "lowest" SCC, which is the one that continues to contain the function just processed. - The call graph structure re-uses SCCs (and RefSCCs) during mutation events for the *highest* entry in the resulting new subgraph, not the lowest. This means that it is necessary to continually update the current SCC or RefSCC as it shifts. This is really surprising and subtle, and took a long time for me to work out. I actually tried changing the call graph to provide the opposite behavior, and it breaks *EVERYTHING*. The graph update algorithms are really deeply tied to this particualr pattern. - When SCCs or RefSCCs are split apart and refined and we continually re-pin our processing to the bottom one in the subgraph, we need to enqueue the newly formed SCCs and RefSCCs for subsequent processing. Queuing them presents a few challenges: 1) SCCs and RefSCCs use wildly different iteration strategies at a high level. We end up needing to converge them on worklist approaches that can be extended in order to be able to handle the mutations. 2) The order of the enqueuing need to remain bottom-up post-order so that we don't get surprising order of visitation for things like the inliner. 3) We need the worklists to have set semantics so we don't duplicate things endlessly. We don't need a *persistent* set though because we always keep processing the bottom node!!!! This is super, super surprising to me and took a long time to convince myself this is correct, but I'm pretty sure it is... Once we sink down to the bottom node, we can't re-split out the same node in any way, and the postorder of the current queue is fixed and unchanging. 4) We need to make sure that the "current" SCC or RefSCC actually gets enqueued here such that we re-visit it because we continue processing a *new*, *bottom* SCC/RefSCC. - We also need the ability to *skip* SCCs and RefSCCs that get merged into a larger component. We even need the ability to skip *nodes* from an SCC that are no longer part of that SCC. This led to the design you see in the patch which uses SetVector-based worklists. The RefSCC worklist is always empty until an update occurs and is just used to handle those RefSCCs created by updates as the others don't even exist yet and are formed on-demand during the bottom-up walk. The SCC worklist is pre-populated from the RefSCC, and we push new SCCs onto it and blacklist existing SCCs on it to get the desired processing. We then *directly* update these when updating the call graph as I was never able to find a satisfactory abstraction around the update strategy. Finally, we need to compute the updates for function passes. This is mostly used as an initial customer of all the update mechanisms to drive their design to at least cover some real set of use cases. There are a bunch of interesting things that came out of doing this: - It is really nice to do this a function at a time because that function is likely hot in the cache. This means we want even the function pass adaptor to support online updates to the call graph! - To update the call graph after arbitrary function pass mutations is quite hard. We have to build a fairly comprehensive set of data structures and then process them. Fortunately, some of this code is related to the code for building the cal graph in the first place. Unfortunately, very little of it makes any sense to share because the nature of what we're doing is so very different. I've factored out the one part that made sense at least. - We need to transfer these updates into the various structures for the CGSCC pass manager. Once those were more sanely worked out, this became relatively easier. But some of those needs necessitated changes to the LazyCallGraph interface to make it significantly easier to extract the changed SCCs from an update operation. - We also need to update the CGSCC analysis manager as the shape of the graph changes. When an SCC is merged away we need to clear analyses associated with it from the analysis manager which we didn't have support for in the analysis manager infrsatructure. New SCCs are easy! But then we have the case that the original SCC has its shape changed but remains in the call graph. There we need to *invalidate* the analyses associated with it. - We also need to invalidate analyses after we *finish* processing an SCC. But the analyses we need to invalidate here are *only those for the newly updated SCC*!!! Because we only continue processing the bottom SCC, if we split SCCs apart the original one gets invalidated once when its shape changes and is not processed farther so its analyses will be correct. It is the bottom SCC which continues being processed and needs to have the "normal" invalidation done based on the preserved analyses set. All of this is mostly background and context for the changes here. Many thanks to all the reviewers who helped here. Especially Sanjoy who caught several interesting bugs in the graph algorithms, David, Sean, and others who all helped with feedback. Differential Revision: http://reviews.llvm.org/D21464 llvm-svn: 279618
2016-08-24 17:37:14 +08:00
Result run(LazyCallGraph::SCC &C, CGSCCAnalysisManager &AM, LazyCallGraph &) {
[PM] Add a unittest for the CGSCC pass manager in the new pass manager system. Previously, this was only being tested with larger integration tests. That makes it hard to isolated specific issues with it, and makes the APIs themselves less well tested. Add a unittest based around the same patterns used for testing the general pass manager. llvm-svn: 261624
2016-02-23 18:02:02 +08:00
++Runs;
return Result(C.size());
}
private:
[PM] Change the static object whose address is used to uniquely identify analyses to have a common type which is enforced rather than using a char object and a `void *` type when used as an identifier. This has a number of advantages. First, it at least helps some of the confusion raised in Justin Lebar's code review of why `void *` was being used everywhere by having a stronger type that connects to documentation about this. However, perhaps more importantly, it addresses a serious issue where the alignment of these pointer-like identifiers was unknown. This made it hard to use them in pointer-like data structures. We were already dodging this in dangerous ways to create the "all analyses" entry. In a subsequent patch I attempted to use these with TinyPtrVector and things fell apart in a very bad way. And it isn't just a compile time or type system issue. Worse than that, the actual alignment of these pointer-like opaque identifiers wasn't guaranteed to be a useful alignment as they were just characters. This change introduces a type to use as the "key" object whose address forms the opaque identifier. This both forces the objects to have proper alignment, and provides type checking that we get it right everywhere. It also makes the types somewhat less mysterious than `void *`. We could go one step further and introduce a truly opaque pointer-like type to return from the `ID()` static function rather than returning `AnalysisKey *`, but that didn't seem to be a clear win so this is just the initial change to get to a reliably typed and aligned object serving is a key for all the analyses. Thanks to Richard Smith and Justin Lebar for helping pick plausible names and avoid making this refactoring many times. =] And thanks to Sean for the super fast review! While here, I've tried to move away from the "PassID" nomenclature entirely as it wasn't really helping and is overloaded with old pass manager constructs. Now we have IDs for analyses, and key objects whose address can be used as IDs. Where possible and clear I've shortened this to just "ID". In a few places I kept "AnalysisID" to make it clear what was being identified. Differential Revision: https://reviews.llvm.org/D27031 llvm-svn: 287783
2016-11-24 01:53:26 +08:00
friend AnalysisInfoMixin<TestSCCAnalysis>;
static AnalysisKey Key;
[PM] Add a unittest for the CGSCC pass manager in the new pass manager system. Previously, this was only being tested with larger integration tests. That makes it hard to isolated specific issues with it, and makes the APIs themselves less well tested. Add a unittest based around the same patterns used for testing the general pass manager. llvm-svn: 261624
2016-02-23 18:02:02 +08:00
int &Runs;
};
[PM] Change the static object whose address is used to uniquely identify analyses to have a common type which is enforced rather than using a char object and a `void *` type when used as an identifier. This has a number of advantages. First, it at least helps some of the confusion raised in Justin Lebar's code review of why `void *` was being used everywhere by having a stronger type that connects to documentation about this. However, perhaps more importantly, it addresses a serious issue where the alignment of these pointer-like identifiers was unknown. This made it hard to use them in pointer-like data structures. We were already dodging this in dangerous ways to create the "all analyses" entry. In a subsequent patch I attempted to use these with TinyPtrVector and things fell apart in a very bad way. And it isn't just a compile time or type system issue. Worse than that, the actual alignment of these pointer-like opaque identifiers wasn't guaranteed to be a useful alignment as they were just characters. This change introduces a type to use as the "key" object whose address forms the opaque identifier. This both forces the objects to have proper alignment, and provides type checking that we get it right everywhere. It also makes the types somewhat less mysterious than `void *`. We could go one step further and introduce a truly opaque pointer-like type to return from the `ID()` static function rather than returning `AnalysisKey *`, but that didn't seem to be a clear win so this is just the initial change to get to a reliably typed and aligned object serving is a key for all the analyses. Thanks to Richard Smith and Justin Lebar for helping pick plausible names and avoid making this refactoring many times. =] And thanks to Sean for the super fast review! While here, I've tried to move away from the "PassID" nomenclature entirely as it wasn't really helping and is overloaded with old pass manager constructs. Now we have IDs for analyses, and key objects whose address can be used as IDs. Where possible and clear I've shortened this to just "ID". In a few places I kept "AnalysisID" to make it clear what was being identified. Differential Revision: https://reviews.llvm.org/D27031 llvm-svn: 287783
2016-11-24 01:53:26 +08:00
AnalysisKey TestSCCAnalysis::Key;
[PM] Add a unittest for the CGSCC pass manager in the new pass manager system. Previously, this was only being tested with larger integration tests. That makes it hard to isolated specific issues with it, and makes the APIs themselves less well tested. Add a unittest based around the same patterns used for testing the general pass manager. llvm-svn: 261624
2016-02-23 18:02:02 +08:00
[PM] Change the static object whose address is used to uniquely identify analyses to have a common type which is enforced rather than using a char object and a `void *` type when used as an identifier. This has a number of advantages. First, it at least helps some of the confusion raised in Justin Lebar's code review of why `void *` was being used everywhere by having a stronger type that connects to documentation about this. However, perhaps more importantly, it addresses a serious issue where the alignment of these pointer-like identifiers was unknown. This made it hard to use them in pointer-like data structures. We were already dodging this in dangerous ways to create the "all analyses" entry. In a subsequent patch I attempted to use these with TinyPtrVector and things fell apart in a very bad way. And it isn't just a compile time or type system issue. Worse than that, the actual alignment of these pointer-like opaque identifiers wasn't guaranteed to be a useful alignment as they were just characters. This change introduces a type to use as the "key" object whose address forms the opaque identifier. This both forces the objects to have proper alignment, and provides type checking that we get it right everywhere. It also makes the types somewhat less mysterious than `void *`. We could go one step further and introduce a truly opaque pointer-like type to return from the `ID()` static function rather than returning `AnalysisKey *`, but that didn't seem to be a clear win so this is just the initial change to get to a reliably typed and aligned object serving is a key for all the analyses. Thanks to Richard Smith and Justin Lebar for helping pick plausible names and avoid making this refactoring many times. =] And thanks to Sean for the super fast review! While here, I've tried to move away from the "PassID" nomenclature entirely as it wasn't really helping and is overloaded with old pass manager constructs. Now we have IDs for analyses, and key objects whose address can be used as IDs. Where possible and clear I've shortened this to just "ID". In a few places I kept "AnalysisID" to make it clear what was being identified. Differential Revision: https://reviews.llvm.org/D27031 llvm-svn: 287783
2016-11-24 01:53:26 +08:00
class TestFunctionAnalysis : public AnalysisInfoMixin<TestFunctionAnalysis> {
[PM] Add a unittest for the CGSCC pass manager in the new pass manager system. Previously, this was only being tested with larger integration tests. That makes it hard to isolated specific issues with it, and makes the APIs themselves less well tested. Add a unittest based around the same patterns used for testing the general pass manager. llvm-svn: 261624
2016-02-23 18:02:02 +08:00
public:
struct Result {
Result(int Count) : InstructionCount(Count) {}
int InstructionCount;
};
TestFunctionAnalysis(int &Runs) : Runs(Runs) {}
[PM] Make the AnalysisManager parameter to run methods a reference. This was originally a pointer to support pass managers which didn't use AnalysisManagers. However, that doesn't realistically come up much and the complexity of supporting it doesn't really make sense. In fact, *many* parts of the pass manager were just assuming the pointer was never null already. This at least makes it much more explicit and clear. llvm-svn: 263219
2016-03-11 19:05:24 +08:00
Result run(Function &F, FunctionAnalysisManager &AM) {
[PM] Add a unittest for the CGSCC pass manager in the new pass manager system. Previously, this was only being tested with larger integration tests. That makes it hard to isolated specific issues with it, and makes the APIs themselves less well tested. Add a unittest based around the same patterns used for testing the general pass manager. llvm-svn: 261624
2016-02-23 18:02:02 +08:00
++Runs;
int Count = 0;
for (Instruction &I : instructions(F)) {
(void)I;
++Count;
}
return Result(Count);
}
private:
[PM] Change the static object whose address is used to uniquely identify analyses to have a common type which is enforced rather than using a char object and a `void *` type when used as an identifier. This has a number of advantages. First, it at least helps some of the confusion raised in Justin Lebar's code review of why `void *` was being used everywhere by having a stronger type that connects to documentation about this. However, perhaps more importantly, it addresses a serious issue where the alignment of these pointer-like identifiers was unknown. This made it hard to use them in pointer-like data structures. We were already dodging this in dangerous ways to create the "all analyses" entry. In a subsequent patch I attempted to use these with TinyPtrVector and things fell apart in a very bad way. And it isn't just a compile time or type system issue. Worse than that, the actual alignment of these pointer-like opaque identifiers wasn't guaranteed to be a useful alignment as they were just characters. This change introduces a type to use as the "key" object whose address forms the opaque identifier. This both forces the objects to have proper alignment, and provides type checking that we get it right everywhere. It also makes the types somewhat less mysterious than `void *`. We could go one step further and introduce a truly opaque pointer-like type to return from the `ID()` static function rather than returning `AnalysisKey *`, but that didn't seem to be a clear win so this is just the initial change to get to a reliably typed and aligned object serving is a key for all the analyses. Thanks to Richard Smith and Justin Lebar for helping pick plausible names and avoid making this refactoring many times. =] And thanks to Sean for the super fast review! While here, I've tried to move away from the "PassID" nomenclature entirely as it wasn't really helping and is overloaded with old pass manager constructs. Now we have IDs for analyses, and key objects whose address can be used as IDs. Where possible and clear I've shortened this to just "ID". In a few places I kept "AnalysisID" to make it clear what was being identified. Differential Revision: https://reviews.llvm.org/D27031 llvm-svn: 287783
2016-11-24 01:53:26 +08:00
friend AnalysisInfoMixin<TestFunctionAnalysis>;
static AnalysisKey Key;
[PM] Add a unittest for the CGSCC pass manager in the new pass manager system. Previously, this was only being tested with larger integration tests. That makes it hard to isolated specific issues with it, and makes the APIs themselves less well tested. Add a unittest based around the same patterns used for testing the general pass manager. llvm-svn: 261624
2016-02-23 18:02:02 +08:00
int &Runs;
};
[PM] Change the static object whose address is used to uniquely identify analyses to have a common type which is enforced rather than using a char object and a `void *` type when used as an identifier. This has a number of advantages. First, it at least helps some of the confusion raised in Justin Lebar's code review of why `void *` was being used everywhere by having a stronger type that connects to documentation about this. However, perhaps more importantly, it addresses a serious issue where the alignment of these pointer-like identifiers was unknown. This made it hard to use them in pointer-like data structures. We were already dodging this in dangerous ways to create the "all analyses" entry. In a subsequent patch I attempted to use these with TinyPtrVector and things fell apart in a very bad way. And it isn't just a compile time or type system issue. Worse than that, the actual alignment of these pointer-like opaque identifiers wasn't guaranteed to be a useful alignment as they were just characters. This change introduces a type to use as the "key" object whose address forms the opaque identifier. This both forces the objects to have proper alignment, and provides type checking that we get it right everywhere. It also makes the types somewhat less mysterious than `void *`. We could go one step further and introduce a truly opaque pointer-like type to return from the `ID()` static function rather than returning `AnalysisKey *`, but that didn't seem to be a clear win so this is just the initial change to get to a reliably typed and aligned object serving is a key for all the analyses. Thanks to Richard Smith and Justin Lebar for helping pick plausible names and avoid making this refactoring many times. =] And thanks to Sean for the super fast review! While here, I've tried to move away from the "PassID" nomenclature entirely as it wasn't really helping and is overloaded with old pass manager constructs. Now we have IDs for analyses, and key objects whose address can be used as IDs. Where possible and clear I've shortened this to just "ID". In a few places I kept "AnalysisID" to make it clear what was being identified. Differential Revision: https://reviews.llvm.org/D27031 llvm-svn: 287783
2016-11-24 01:53:26 +08:00
AnalysisKey TestFunctionAnalysis::Key;
[PM] Add a unittest for the CGSCC pass manager in the new pass manager system. Previously, this was only being tested with larger integration tests. That makes it hard to isolated specific issues with it, and makes the APIs themselves less well tested. Add a unittest based around the same patterns used for testing the general pass manager. llvm-svn: 261624
2016-02-23 18:02:02 +08:00
[PM] Change the static object whose address is used to uniquely identify analyses to have a common type which is enforced rather than using a char object and a `void *` type when used as an identifier. This has a number of advantages. First, it at least helps some of the confusion raised in Justin Lebar's code review of why `void *` was being used everywhere by having a stronger type that connects to documentation about this. However, perhaps more importantly, it addresses a serious issue where the alignment of these pointer-like identifiers was unknown. This made it hard to use them in pointer-like data structures. We were already dodging this in dangerous ways to create the "all analyses" entry. In a subsequent patch I attempted to use these with TinyPtrVector and things fell apart in a very bad way. And it isn't just a compile time or type system issue. Worse than that, the actual alignment of these pointer-like opaque identifiers wasn't guaranteed to be a useful alignment as they were just characters. This change introduces a type to use as the "key" object whose address forms the opaque identifier. This both forces the objects to have proper alignment, and provides type checking that we get it right everywhere. It also makes the types somewhat less mysterious than `void *`. We could go one step further and introduce a truly opaque pointer-like type to return from the `ID()` static function rather than returning `AnalysisKey *`, but that didn't seem to be a clear win so this is just the initial change to get to a reliably typed and aligned object serving is a key for all the analyses. Thanks to Richard Smith and Justin Lebar for helping pick plausible names and avoid making this refactoring many times. =] And thanks to Sean for the super fast review! While here, I've tried to move away from the "PassID" nomenclature entirely as it wasn't really helping and is overloaded with old pass manager constructs. Now we have IDs for analyses, and key objects whose address can be used as IDs. Where possible and clear I've shortened this to just "ID". In a few places I kept "AnalysisID" to make it clear what was being identified. Differential Revision: https://reviews.llvm.org/D27031 llvm-svn: 287783
2016-11-24 01:53:26 +08:00
class TestImmutableFunctionAnalysis
: public AnalysisInfoMixin<TestImmutableFunctionAnalysis> {
[PM] Remove an overly aggressive assert now that I can actually test the pattern that triggers it. This essentially requires an immutable function analysis, as that will survive anything we do to invalidate it. When we have such patterns, the function analysis manager will not get cleared between runs of the proxy. If we actually need an assert about how things are queried, we can add more elaborate machinery for computing it, but so far I'm not aware of significant value provided. Thanks to Justin Lebar for noticing this when he made a (seemingly innocuous) change to FunctionAttrs that is enough to trigger it in one test there. Now it is covered by a direct test of the pass manager code. llvm-svn: 261627
2016-02-23 18:47:57 +08:00
public:
struct Result {
[PM] Extend the explicit 'invalidate' method API on analysis results to accept an Invalidator that allows them to invalidate themselves if their dependencies are in turn invalidated. Rather than recording the dependency graph ahead of time when analysis get results from other analyses, this simply lets each result trigger the immediate invalidation of any analyses they actually depend on. They do this in a way that has three nice properties: 1) They don't have to handle transitive dependencies because the infrastructure will recurse for them. 2) The invalidate methods are still called only once. We just dynamically discover the necessary topological ordering, everything is memoized nicely. 3) The infrastructure still provides a default implementation and can access it so that only analyses which have dependencies need to do anything custom. To make this work at all, the invalidation logic also has to defer the deletion of the result objects themselves so that they can remain alive until we have collected the complete set of results to invalidate. A unittest is added here that has exactly the dependency pattern we are concerned with. It hit the use-after-free described by Sean in much detail in the long thread about analysis invalidation before this change, and even in an intermediate form of this change where we failed to defer the deletion of the result objects. There is an important problem with doing dependency invalidation that *isn't* solved here: we don't *enforce* that results correctly invalidate all the analyses whose results they depend on. I actually looked at what it would take to do that, and it isn't as hard as I had thought but the complexity it introduces seems very likely to outweigh the benefit. The technique would be to provide a base class for an analysis result that would be populated with other results, and automatically provide the invalidate method which immediately does the correct thing. This approach has some nice pros IMO: - Handles the case we care about and nothing else: only *results* that depend on other analyses trigger extra invalidation. - Localized to the result rather than centralized in the analysis manager. - Ties the storage of the reference to another result to the triggering of the invalidation of that analysis. - Still supports extending invalidation in customized ways. But the down sides here are: - Very heavy-weight meta-programming is needed to provide this base class. - Requires a pretty awful API for accessing the dependencies. Ultimately, I fear it will not pull its weight. But we can re-evaluate this at any point if we start discovering consistent problems where the invalidation and dependencies get out of sync. It will fit as a clean layer on top of the facilities in this patch that we can add if and when we need it. Note that I'm not really thrilled with the names for these APIs... The name "Invalidator" seems ok but not great. The method name "invalidate" also. In review some improvements were suggested, but they really need *other* uses of these terms to be updated as well so I'm going to do that in a follow-up commit. I'm working on the actual fixes to various analyses that need to use these, but I want to try to get tests for each of them so we don't regress. And those changes are seperable and obvious so once this goes in I should be able to roll them out throughout LLVM. Many thanks to Sean, Justin, and others for help reviewing here. Differential Revision: https://reviews.llvm.org/D23738 llvm-svn: 288077
2016-11-29 06:04:31 +08:00
bool invalidate(Function &, const PreservedAnalyses &,
FunctionAnalysisManager::Invalidator &) {
return false;
}
[PM] Remove an overly aggressive assert now that I can actually test the pattern that triggers it. This essentially requires an immutable function analysis, as that will survive anything we do to invalidate it. When we have such patterns, the function analysis manager will not get cleared between runs of the proxy. If we actually need an assert about how things are queried, we can add more elaborate machinery for computing it, but so far I'm not aware of significant value provided. Thanks to Justin Lebar for noticing this when he made a (seemingly innocuous) change to FunctionAttrs that is enough to trigger it in one test there. Now it is covered by a direct test of the pass manager code. llvm-svn: 261627
2016-02-23 18:47:57 +08:00
};
TestImmutableFunctionAnalysis(int &Runs) : Runs(Runs) {}
[PM] Make the AnalysisManager parameter to run methods a reference. This was originally a pointer to support pass managers which didn't use AnalysisManagers. However, that doesn't realistically come up much and the complexity of supporting it doesn't really make sense. In fact, *many* parts of the pass manager were just assuming the pointer was never null already. This at least makes it much more explicit and clear. llvm-svn: 263219
2016-03-11 19:05:24 +08:00
Result run(Function &F, FunctionAnalysisManager &AM) {
[PM] Remove an overly aggressive assert now that I can actually test the pattern that triggers it. This essentially requires an immutable function analysis, as that will survive anything we do to invalidate it. When we have such patterns, the function analysis manager will not get cleared between runs of the proxy. If we actually need an assert about how things are queried, we can add more elaborate machinery for computing it, but so far I'm not aware of significant value provided. Thanks to Justin Lebar for noticing this when he made a (seemingly innocuous) change to FunctionAttrs that is enough to trigger it in one test there. Now it is covered by a direct test of the pass manager code. llvm-svn: 261627
2016-02-23 18:47:57 +08:00
++Runs;
return Result();
}
private:
[PM] Change the static object whose address is used to uniquely identify analyses to have a common type which is enforced rather than using a char object and a `void *` type when used as an identifier. This has a number of advantages. First, it at least helps some of the confusion raised in Justin Lebar's code review of why `void *` was being used everywhere by having a stronger type that connects to documentation about this. However, perhaps more importantly, it addresses a serious issue where the alignment of these pointer-like identifiers was unknown. This made it hard to use them in pointer-like data structures. We were already dodging this in dangerous ways to create the "all analyses" entry. In a subsequent patch I attempted to use these with TinyPtrVector and things fell apart in a very bad way. And it isn't just a compile time or type system issue. Worse than that, the actual alignment of these pointer-like opaque identifiers wasn't guaranteed to be a useful alignment as they were just characters. This change introduces a type to use as the "key" object whose address forms the opaque identifier. This both forces the objects to have proper alignment, and provides type checking that we get it right everywhere. It also makes the types somewhat less mysterious than `void *`. We could go one step further and introduce a truly opaque pointer-like type to return from the `ID()` static function rather than returning `AnalysisKey *`, but that didn't seem to be a clear win so this is just the initial change to get to a reliably typed and aligned object serving is a key for all the analyses. Thanks to Richard Smith and Justin Lebar for helping pick plausible names and avoid making this refactoring many times. =] And thanks to Sean for the super fast review! While here, I've tried to move away from the "PassID" nomenclature entirely as it wasn't really helping and is overloaded with old pass manager constructs. Now we have IDs for analyses, and key objects whose address can be used as IDs. Where possible and clear I've shortened this to just "ID". In a few places I kept "AnalysisID" to make it clear what was being identified. Differential Revision: https://reviews.llvm.org/D27031 llvm-svn: 287783
2016-11-24 01:53:26 +08:00
friend AnalysisInfoMixin<TestImmutableFunctionAnalysis>;
static AnalysisKey Key;
[PM] Remove an overly aggressive assert now that I can actually test the pattern that triggers it. This essentially requires an immutable function analysis, as that will survive anything we do to invalidate it. When we have such patterns, the function analysis manager will not get cleared between runs of the proxy. If we actually need an assert about how things are queried, we can add more elaborate machinery for computing it, but so far I'm not aware of significant value provided. Thanks to Justin Lebar for noticing this when he made a (seemingly innocuous) change to FunctionAttrs that is enough to trigger it in one test there. Now it is covered by a direct test of the pass manager code. llvm-svn: 261627
2016-02-23 18:47:57 +08:00
int &Runs;
};
[PM] Change the static object whose address is used to uniquely identify analyses to have a common type which is enforced rather than using a char object and a `void *` type when used as an identifier. This has a number of advantages. First, it at least helps some of the confusion raised in Justin Lebar's code review of why `void *` was being used everywhere by having a stronger type that connects to documentation about this. However, perhaps more importantly, it addresses a serious issue where the alignment of these pointer-like identifiers was unknown. This made it hard to use them in pointer-like data structures. We were already dodging this in dangerous ways to create the "all analyses" entry. In a subsequent patch I attempted to use these with TinyPtrVector and things fell apart in a very bad way. And it isn't just a compile time or type system issue. Worse than that, the actual alignment of these pointer-like opaque identifiers wasn't guaranteed to be a useful alignment as they were just characters. This change introduces a type to use as the "key" object whose address forms the opaque identifier. This both forces the objects to have proper alignment, and provides type checking that we get it right everywhere. It also makes the types somewhat less mysterious than `void *`. We could go one step further and introduce a truly opaque pointer-like type to return from the `ID()` static function rather than returning `AnalysisKey *`, but that didn't seem to be a clear win so this is just the initial change to get to a reliably typed and aligned object serving is a key for all the analyses. Thanks to Richard Smith and Justin Lebar for helping pick plausible names and avoid making this refactoring many times. =] And thanks to Sean for the super fast review! While here, I've tried to move away from the "PassID" nomenclature entirely as it wasn't really helping and is overloaded with old pass manager constructs. Now we have IDs for analyses, and key objects whose address can be used as IDs. Where possible and clear I've shortened this to just "ID". In a few places I kept "AnalysisID" to make it clear what was being identified. Differential Revision: https://reviews.llvm.org/D27031 llvm-svn: 287783
2016-11-24 01:53:26 +08:00
AnalysisKey TestImmutableFunctionAnalysis::Key;
[PM] Remove an overly aggressive assert now that I can actually test the pattern that triggers it. This essentially requires an immutable function analysis, as that will survive anything we do to invalidate it. When we have such patterns, the function analysis manager will not get cleared between runs of the proxy. If we actually need an assert about how things are queried, we can add more elaborate machinery for computing it, but so far I'm not aware of significant value provided. Thanks to Justin Lebar for noticing this when he made a (seemingly innocuous) change to FunctionAttrs that is enough to trigger it in one test there. Now it is covered by a direct test of the pass manager code. llvm-svn: 261627
2016-02-23 18:47:57 +08:00
[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 14:34:44 +08:00
struct LambdaModulePass : public PassInfoMixin<LambdaModulePass> {
template <typename T>
LambdaModulePass(T &&Arg) : Func(std::forward<T>(Arg)) {}
PreservedAnalyses run(Module &F, ModuleAnalysisManager &AM) {
return Func(F, AM);
}
std::function<PreservedAnalyses(Module &, ModuleAnalysisManager &)> Func;
};
[PM] (NFC) Refactor the CGSCC pass manager tests to use lambda-based passes. This simplifies the test some and makes it more focused and clear what is being tested. It will also make it much easier to extend with further testing of different pass behaviors. I've also replaced a pointless module pass with running the requires pass directly as that is all that it was really doing. llvm-svn: 280444
2016-09-02 09:08:04 +08:00
struct LambdaSCCPass : public PassInfoMixin<LambdaSCCPass> {
template <typename T> LambdaSCCPass(T &&Arg) : Func(std::forward<T>(Arg)) {}
[PM] Add a unittest for the CGSCC pass manager in the new pass manager system. Previously, this was only being tested with larger integration tests. That makes it hard to isolated specific issues with it, and makes the APIs themselves less well tested. Add a unittest based around the same patterns used for testing the general pass manager. llvm-svn: 261624
2016-02-23 18:02:02 +08:00
[PM] Introduce basic update capabilities to the new PM's CGSCC pass manager, including both plumbing and logic to handle function pass updates. There are three fundamentally tied changes here: 1) Plumbing *some* mechanism for updating the CGSCC pass manager as the CG changes while passes are running. 2) Changing the CGSCC pass manager infrastructure to have support for the underlying graph to mutate mid-pass run. 3) Actually updating the CG after function passes run. I can separate them if necessary, but I think its really useful to have them together as the needs of #3 drove #2, and that in turn drove #1. The plumbing technique is to extend the "run" method signature with extra arguments. We provide the call graph that intrinsically is available as it is the basis of the pass manager's IR units, and an output parameter that records the results of updating the call graph during an SCC passes's run. Note that "...UpdateResult" isn't a *great* name here... suggestions very welcome. I tried a pretty frustrating number of different data structures and such for the innards of the update result. Every other one failed for one reason or another. Sometimes I just couldn't keep the layers of complexity right in my head. The thing that really worked was to just directly provide access to the underlying structures used to walk the call graph so that their updates could be informed by the *particular* nature of the change to the graph. The technique for how to make the pass management infrastructure cope with mutating graphs was also something that took a really, really large number of iterations to get to a place where I was happy. Here are some of the considerations that drove the design: - We operate at three levels within the infrastructure: RefSCC, SCC, and Node. In each case, we are working bottom up and so we want to continue to iterate on the "lowest" node as the graph changes. Look at how we iterate over nodes in an SCC running function passes as those function passes mutate the CG. We continue to iterate on the "lowest" SCC, which is the one that continues to contain the function just processed. - The call graph structure re-uses SCCs (and RefSCCs) during mutation events for the *highest* entry in the resulting new subgraph, not the lowest. This means that it is necessary to continually update the current SCC or RefSCC as it shifts. This is really surprising and subtle, and took a long time for me to work out. I actually tried changing the call graph to provide the opposite behavior, and it breaks *EVERYTHING*. The graph update algorithms are really deeply tied to this particualr pattern. - When SCCs or RefSCCs are split apart and refined and we continually re-pin our processing to the bottom one in the subgraph, we need to enqueue the newly formed SCCs and RefSCCs for subsequent processing. Queuing them presents a few challenges: 1) SCCs and RefSCCs use wildly different iteration strategies at a high level. We end up needing to converge them on worklist approaches that can be extended in order to be able to handle the mutations. 2) The order of the enqueuing need to remain bottom-up post-order so that we don't get surprising order of visitation for things like the inliner. 3) We need the worklists to have set semantics so we don't duplicate things endlessly. We don't need a *persistent* set though because we always keep processing the bottom node!!!! This is super, super surprising to me and took a long time to convince myself this is correct, but I'm pretty sure it is... Once we sink down to the bottom node, we can't re-split out the same node in any way, and the postorder of the current queue is fixed and unchanging. 4) We need to make sure that the "current" SCC or RefSCC actually gets enqueued here such that we re-visit it because we continue processing a *new*, *bottom* SCC/RefSCC. - We also need the ability to *skip* SCCs and RefSCCs that get merged into a larger component. We even need the ability to skip *nodes* from an SCC that are no longer part of that SCC. This led to the design you see in the patch which uses SetVector-based worklists. The RefSCC worklist is always empty until an update occurs and is just used to handle those RefSCCs created by updates as the others don't even exist yet and are formed on-demand during the bottom-up walk. The SCC worklist is pre-populated from the RefSCC, and we push new SCCs onto it and blacklist existing SCCs on it to get the desired processing. We then *directly* update these when updating the call graph as I was never able to find a satisfactory abstraction around the update strategy. Finally, we need to compute the updates for function passes. This is mostly used as an initial customer of all the update mechanisms to drive their design to at least cover some real set of use cases. There are a bunch of interesting things that came out of doing this: - It is really nice to do this a function at a time because that function is likely hot in the cache. This means we want even the function pass adaptor to support online updates to the call graph! - To update the call graph after arbitrary function pass mutations is quite hard. We have to build a fairly comprehensive set of data structures and then process them. Fortunately, some of this code is related to the code for building the cal graph in the first place. Unfortunately, very little of it makes any sense to share because the nature of what we're doing is so very different. I've factored out the one part that made sense at least. - We need to transfer these updates into the various structures for the CGSCC pass manager. Once those were more sanely worked out, this became relatively easier. But some of those needs necessitated changes to the LazyCallGraph interface to make it significantly easier to extract the changed SCCs from an update operation. - We also need to update the CGSCC analysis manager as the shape of the graph changes. When an SCC is merged away we need to clear analyses associated with it from the analysis manager which we didn't have support for in the analysis manager infrsatructure. New SCCs are easy! But then we have the case that the original SCC has its shape changed but remains in the call graph. There we need to *invalidate* the analyses associated with it. - We also need to invalidate analyses after we *finish* processing an SCC. But the analyses we need to invalidate here are *only those for the newly updated SCC*!!! Because we only continue processing the bottom SCC, if we split SCCs apart the original one gets invalidated once when its shape changes and is not processed farther so its analyses will be correct. It is the bottom SCC which continues being processed and needs to have the "normal" invalidation done based on the preserved analyses set. All of this is mostly background and context for the changes here. Many thanks to all the reviewers who helped here. Especially Sanjoy who caught several interesting bugs in the graph algorithms, David, Sean, and others who all helped with feedback. Differential Revision: http://reviews.llvm.org/D21464 llvm-svn: 279618
2016-08-24 17:37:14 +08:00
PreservedAnalyses run(LazyCallGraph::SCC &C, CGSCCAnalysisManager &AM,
LazyCallGraph &CG, CGSCCUpdateResult &UR) {
[PM] (NFC) Refactor the CGSCC pass manager tests to use lambda-based passes. This simplifies the test some and makes it more focused and clear what is being tested. It will also make it much easier to extend with further testing of different pass behaviors. I've also replaced a pointless module pass with running the requires pass directly as that is all that it was really doing. llvm-svn: 280444
2016-09-02 09:08:04 +08:00
return Func(C, AM, CG, UR);
[PM] Add a unittest for the CGSCC pass manager in the new pass manager system. Previously, this was only being tested with larger integration tests. That makes it hard to isolated specific issues with it, and makes the APIs themselves less well tested. Add a unittest based around the same patterns used for testing the general pass manager. llvm-svn: 261624
2016-02-23 18:02:02 +08:00
}
[PM] (NFC) Refactor the CGSCC pass manager tests to use lambda-based passes. This simplifies the test some and makes it more focused and clear what is being tested. It will also make it much easier to extend with further testing of different pass behaviors. I've also replaced a pointless module pass with running the requires pass directly as that is all that it was really doing. llvm-svn: 280444
2016-09-02 09:08:04 +08:00
std::function<PreservedAnalyses(LazyCallGraph::SCC &, CGSCCAnalysisManager &,
LazyCallGraph &, CGSCCUpdateResult &)>
Func;
[PM] Add a unittest for the CGSCC pass manager in the new pass manager system. Previously, this was only being tested with larger integration tests. That makes it hard to isolated specific issues with it, and makes the APIs themselves less well tested. Add a unittest based around the same patterns used for testing the general pass manager. llvm-svn: 261624
2016-02-23 18:02:02 +08:00
};
[PM] (NFC) Refactor the CGSCC pass manager tests to use lambda-based passes. This simplifies the test some and makes it more focused and clear what is being tested. It will also make it much easier to extend with further testing of different pass behaviors. I've also replaced a pointless module pass with running the requires pass directly as that is all that it was really doing. llvm-svn: 280444
2016-09-02 09:08:04 +08:00
struct LambdaFunctionPass : public PassInfoMixin<LambdaFunctionPass> {
[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 14:34:44 +08:00
template <typename T>
LambdaFunctionPass(T &&Arg) : Func(std::forward<T>(Arg)) {}
[PM] Add a unittest for the CGSCC pass manager in the new pass manager system. Previously, this was only being tested with larger integration tests. That makes it hard to isolated specific issues with it, and makes the APIs themselves less well tested. Add a unittest based around the same patterns used for testing the general pass manager. llvm-svn: 261624
2016-02-23 18:02:02 +08:00
[PM] (NFC) Refactor the CGSCC pass manager tests to use lambda-based passes. This simplifies the test some and makes it more focused and clear what is being tested. It will also make it much easier to extend with further testing of different pass behaviors. I've also replaced a pointless module pass with running the requires pass directly as that is all that it was really doing. llvm-svn: 280444
2016-09-02 09:08:04 +08:00
PreservedAnalyses run(Function &F, FunctionAnalysisManager &AM) {
return Func(F, AM);
[PM] Add a unittest for the CGSCC pass manager in the new pass manager system. Previously, this was only being tested with larger integration tests. That makes it hard to isolated specific issues with it, and makes the APIs themselves less well tested. Add a unittest based around the same patterns used for testing the general pass manager. llvm-svn: 261624
2016-02-23 18:02:02 +08:00
}
[PM] (NFC) Refactor the CGSCC pass manager tests to use lambda-based passes. This simplifies the test some and makes it more focused and clear what is being tested. It will also make it much easier to extend with further testing of different pass behaviors. I've also replaced a pointless module pass with running the requires pass directly as that is all that it was really doing. llvm-svn: 280444
2016-09-02 09:08:04 +08:00
std::function<PreservedAnalyses(Function &, FunctionAnalysisManager &)> Func;
[PM] Add a unittest for the CGSCC pass manager in the new pass manager system. Previously, this was only being tested with larger integration tests. That makes it hard to isolated specific issues with it, and makes the APIs themselves less well tested. Add a unittest based around the same patterns used for testing the general pass manager. llvm-svn: 261624
2016-02-23 18:02:02 +08:00
};
[PM] Sink the module parsing from the fixture to the test as subsequent tests will want different IR. Wanted this when writing tests for the proposed CG update stuff, and this is an easily separable piece. llvm-svn: 273973
2016-06-28 08:38:42 +08:00
std::unique_ptr<Module> parseIR(const char *IR) {
// We just use a static context here. This is never called from multiple
// threads so it is harmless no matter how it is implemented. We just need
// the context to outlive the module which it does.
static LLVMContext C;
[PM] Add a unittest for the CGSCC pass manager in the new pass manager system. Previously, this was only being tested with larger integration tests. That makes it hard to isolated specific issues with it, and makes the APIs themselves less well tested. Add a unittest based around the same patterns used for testing the general pass manager. llvm-svn: 261624
2016-02-23 18:02:02 +08:00
SMDiagnostic Err;
return parseAssemblyString(IR, Err, C);
}
[PM] (NFC) Split the IR parsing into a fixture so that I can split out more testing into other test routines while using the same core module. llvm-svn: 280446
2016-09-02 09:14:05 +08:00
class CGSCCPassManagerTest : public ::testing::Test {
protected:
LLVMContext Context;
[PM] Refactor this unittest a bit to remove duplicated code. This was suggested at one point during code review and I deferred it to a follow-up commit. llvm-svn: 282383
2016-09-26 14:29:21 +08:00
FunctionAnalysisManager FAM;
CGSCCAnalysisManager CGAM;
ModuleAnalysisManager MAM;
[PM] (NFC) Split the IR parsing into a fixture so that I can split out more testing into other test routines while using the same core module. llvm-svn: 280446
2016-09-02 09:14:05 +08:00
std::unique_ptr<Module> M;
public:
CGSCCPassManagerTest()
[PM] Refactor this unittest a bit to remove duplicated code. This was suggested at one point during code review and I deferred it to a follow-up commit. llvm-svn: 282383
2016-09-26 14:29:21 +08:00
: FAM(/*DebugLogging*/ true), CGAM(/*DebugLogging*/ true),
[PM] Add an ASCII-art diagram for the call graph in the CGSCC unit test. No functionality changed. llvm-svn: 288013
2016-11-28 11:40:33 +08:00
MAM(/*DebugLogging*/ true),
M(parseIR(
// Define a module with the following call graph, where calls go
// out the bottom of nodes and enter the top:
//
// f
// |\ _
// | \ / |
// g h1 |
// | | |
// | h2 |
// | | |
// | h3 |
// | / \_/
// |/
// x
//
"define void @f() {\n"
"entry:\n"
" call void @g()\n"
" call void @h1()\n"
" ret void\n"
"}\n"
"define void @g() {\n"
"entry:\n"
" call void @g()\n"
" call void @x()\n"
" ret void\n"
"}\n"
"define void @h1() {\n"
"entry:\n"
" call void @h2()\n"
" ret void\n"
"}\n"
"define void @h2() {\n"
"entry:\n"
" call void @h3()\n"
" call void @x()\n"
" ret void\n"
"}\n"
"define void @h3() {\n"
"entry:\n"
" call void @h1()\n"
" ret void\n"
"}\n"
"define void @x() {\n"
"entry:\n"
" ret void\n"
"}\n")) {
[PM] Refactor this unittest a bit to remove duplicated code. This was suggested at one point during code review and I deferred it to a follow-up commit. llvm-svn: 282383
2016-09-26 14:29:21 +08:00
MAM.registerPass([&] { return LazyCallGraphAnalysis(); });
MAM.registerPass([&] { return FunctionAnalysisManagerModuleProxy(FAM); });
MAM.registerPass([&] { return CGSCCAnalysisManagerModuleProxy(CGAM); });
[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 14:34:44 +08:00
CGAM.registerPass([&] { return FunctionAnalysisManagerCGSCCProxy(); });
[PM] Refactor this unittest a bit to remove duplicated code. This was suggested at one point during code review and I deferred it to a follow-up commit. llvm-svn: 282383
2016-09-26 14:29:21 +08:00
CGAM.registerPass([&] { return ModuleAnalysisManagerCGSCCProxy(MAM); });
FAM.registerPass([&] { return CGSCCAnalysisManagerFunctionProxy(CGAM); });
FAM.registerPass([&] { return ModuleAnalysisManagerFunctionProxy(MAM); });
}
[PM] (NFC) Split the IR parsing into a fixture so that I can split out more testing into other test routines while using the same core module. llvm-svn: 280446
2016-09-02 09:14:05 +08:00
};
TEST_F(CGSCCPassManagerTest, Basic) {
[PM] Add a unittest for the CGSCC pass manager in the new pass manager system. Previously, this was only being tested with larger integration tests. That makes it hard to isolated specific issues with it, and makes the APIs themselves less well tested. Add a unittest based around the same patterns used for testing the general pass manager. llvm-svn: 261624
2016-02-23 18:02:02 +08:00
int FunctionAnalysisRuns = 0;
FAM.registerPass([&] { return TestFunctionAnalysis(FunctionAnalysisRuns); });
[PM] Remove an overly aggressive assert now that I can actually test the pattern that triggers it. This essentially requires an immutable function analysis, as that will survive anything we do to invalidate it. When we have such patterns, the function analysis manager will not get cleared between runs of the proxy. If we actually need an assert about how things are queried, we can add more elaborate machinery for computing it, but so far I'm not aware of significant value provided. Thanks to Justin Lebar for noticing this when he made a (seemingly innocuous) change to FunctionAttrs that is enough to trigger it in one test there. Now it is covered by a direct test of the pass manager code. llvm-svn: 261627
2016-02-23 18:47:57 +08:00
int ImmutableFunctionAnalysisRuns = 0;
FAM.registerPass([&] {
return TestImmutableFunctionAnalysis(ImmutableFunctionAnalysisRuns);
});
[PM] Add a unittest for the CGSCC pass manager in the new pass manager system. Previously, this was only being tested with larger integration tests. That makes it hard to isolated specific issues with it, and makes the APIs themselves less well tested. Add a unittest based around the same patterns used for testing the general pass manager. llvm-svn: 261624
2016-02-23 18:02:02 +08:00
int SCCAnalysisRuns = 0;
CGAM.registerPass([&] { return TestSCCAnalysis(SCCAnalysisRuns); });
int ModuleAnalysisRuns = 0;
MAM.registerPass([&] { return TestModuleAnalysis(ModuleAnalysisRuns); });
ModulePassManager MPM(/*DebugLogging*/ true);
[PM] (NFC) Refactor the CGSCC pass manager tests to use lambda-based passes. This simplifies the test some and makes it more focused and clear what is being tested. It will also make it much easier to extend with further testing of different pass behaviors. I've also replaced a pointless module pass with running the requires pass directly as that is all that it was really doing. llvm-svn: 280444
2016-09-02 09:08:04 +08:00
MPM.addPass(RequireAnalysisPass<TestModuleAnalysis, Module>());
[PM] Add a unittest for the CGSCC pass manager in the new pass manager system. Previously, this was only being tested with larger integration tests. That makes it hard to isolated specific issues with it, and makes the APIs themselves less well tested. Add a unittest based around the same patterns used for testing the general pass manager. llvm-svn: 261624
2016-02-23 18:02:02 +08:00
CGSCCPassManager CGPM1(/*DebugLogging*/ true);
[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 14:34:44 +08:00
FunctionPassManager FPM1(/*DebugLogging*/ true);
int FunctionPassRunCount1 = 0;
FPM1.addPass(LambdaFunctionPass([&](Function &, FunctionAnalysisManager &) {
++FunctionPassRunCount1;
return PreservedAnalyses::none();
}));
CGPM1.addPass(createCGSCCToFunctionPassAdaptor(std::move(FPM1)));
[PM] Add a unittest for the CGSCC pass manager in the new pass manager system. Previously, this was only being tested with larger integration tests. That makes it hard to isolated specific issues with it, and makes the APIs themselves less well tested. Add a unittest based around the same patterns used for testing the general pass manager. llvm-svn: 261624
2016-02-23 18:02:02 +08:00
int SCCPassRunCount1 = 0;
int AnalyzedInstrCount1 = 0;
int AnalyzedSCCFunctionCount1 = 0;
int AnalyzedModuleFunctionCount1 = 0;
[PM] (NFC) Refactor the CGSCC pass manager tests to use lambda-based passes. This simplifies the test some and makes it more focused and clear what is being tested. It will also make it much easier to extend with further testing of different pass behaviors. I've also replaced a pointless module pass with running the requires pass directly as that is all that it was really doing. llvm-svn: 280444
2016-09-02 09:08:04 +08:00
CGPM1.addPass(
LambdaSCCPass([&](LazyCallGraph::SCC &C, CGSCCAnalysisManager &AM,
LazyCallGraph &CG, CGSCCUpdateResult &UR) {
++SCCPassRunCount1;
const ModuleAnalysisManager &MAM =
AM.getResult<ModuleAnalysisManagerCGSCCProxy>(C, CG).getManager();
FunctionAnalysisManager &FAM =
AM.getResult<FunctionAnalysisManagerCGSCCProxy>(C, CG).getManager();
if (TestModuleAnalysis::Result *TMA =
MAM.getCachedResult<TestModuleAnalysis>(
*C.begin()->getFunction().getParent()))
AnalyzedModuleFunctionCount1 += TMA->FunctionCount;
TestSCCAnalysis::Result &AR = AM.getResult<TestSCCAnalysis>(C, CG);
AnalyzedSCCFunctionCount1 += AR.FunctionCount;
for (LazyCallGraph::Node &N : C) {
TestFunctionAnalysis::Result &FAR =
FAM.getResult<TestFunctionAnalysis>(N.getFunction());
AnalyzedInstrCount1 += FAR.InstructionCount;
// Just ensure we get the immutable results.
(void)FAM.getResult<TestImmutableFunctionAnalysis>(N.getFunction());
}
return PreservedAnalyses::all();
}));
[PM] Add a unittest for the CGSCC pass manager in the new pass manager system. Previously, this was only being tested with larger integration tests. That makes it hard to isolated specific issues with it, and makes the APIs themselves less well tested. Add a unittest based around the same patterns used for testing the general pass manager. llvm-svn: 261624
2016-02-23 18:02:02 +08:00
[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 14:34:44 +08:00
FunctionPassManager FPM2(/*DebugLogging*/ true);
int FunctionPassRunCount2 = 0;
FPM2.addPass(LambdaFunctionPass([&](Function &, FunctionAnalysisManager &) {
++FunctionPassRunCount2;
return PreservedAnalyses::none();
[PM] (NFC) Refactor the CGSCC pass manager tests to use lambda-based passes. This simplifies the test some and makes it more focused and clear what is being tested. It will also make it much easier to extend with further testing of different pass behaviors. I've also replaced a pointless module pass with running the requires pass directly as that is all that it was really doing. llvm-svn: 280444
2016-09-02 09:08:04 +08:00
}));
[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 14:34:44 +08:00
CGPM1.addPass(createCGSCCToFunctionPassAdaptor(std::move(FPM2)));
[PM] Add a unittest for the CGSCC pass manager in the new pass manager system. Previously, this was only being tested with larger integration tests. That makes it hard to isolated specific issues with it, and makes the APIs themselves less well tested. Add a unittest based around the same patterns used for testing the general pass manager. llvm-svn: 261624
2016-02-23 18:02:02 +08:00
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM1)));
[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 14:34:44 +08:00
FunctionPassManager FPM3(/*DebugLogging*/ true);
int FunctionPassRunCount3 = 0;
FPM3.addPass(LambdaFunctionPass([&](Function &, FunctionAnalysisManager &) {
++FunctionPassRunCount3;
return PreservedAnalyses::none();
}));
MPM.addPass(createModuleToFunctionPassAdaptor(std::move(FPM3)));
[PM] Make the AnalysisManager parameter to run methods a reference. This was originally a pointer to support pass managers which didn't use AnalysisManagers. However, that doesn't realistically come up much and the complexity of supporting it doesn't really make sense. In fact, *many* parts of the pass manager were just assuming the pointer was never null already. This at least makes it much more explicit and clear. llvm-svn: 263219
2016-03-11 19:05:24 +08:00
MPM.run(*M, MAM);
[PM] Add a unittest for the CGSCC pass manager in the new pass manager system. Previously, this was only being tested with larger integration tests. That makes it hard to isolated specific issues with it, and makes the APIs themselves less well tested. Add a unittest based around the same patterns used for testing the general pass manager. llvm-svn: 261624
2016-02-23 18:02:02 +08:00
[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 14:34:44 +08:00
EXPECT_EQ(4, SCCPassRunCount1);
EXPECT_EQ(6, FunctionPassRunCount1);
EXPECT_EQ(6, FunctionPassRunCount2);
EXPECT_EQ(6, FunctionPassRunCount3);
[PM] Add a unittest for the CGSCC pass manager in the new pass manager system. Previously, this was only being tested with larger integration tests. That makes it hard to isolated specific issues with it, and makes the APIs themselves less well tested. Add a unittest based around the same patterns used for testing the general pass manager. llvm-svn: 261624
2016-02-23 18:02:02 +08:00
EXPECT_EQ(1, ModuleAnalysisRuns);
EXPECT_EQ(4, SCCAnalysisRuns);
EXPECT_EQ(6, FunctionAnalysisRuns);
[PM] Remove an overly aggressive assert now that I can actually test the pattern that triggers it. This essentially requires an immutable function analysis, as that will survive anything we do to invalidate it. When we have such patterns, the function analysis manager will not get cleared between runs of the proxy. If we actually need an assert about how things are queried, we can add more elaborate machinery for computing it, but so far I'm not aware of significant value provided. Thanks to Justin Lebar for noticing this when he made a (seemingly innocuous) change to FunctionAttrs that is enough to trigger it in one test there. Now it is covered by a direct test of the pass manager code. llvm-svn: 261627
2016-02-23 18:47:57 +08:00
EXPECT_EQ(6, ImmutableFunctionAnalysisRuns);
[PM] Add a unittest for the CGSCC pass manager in the new pass manager system. Previously, this was only being tested with larger integration tests. That makes it hard to isolated specific issues with it, and makes the APIs themselves less well tested. Add a unittest based around the same patterns used for testing the general pass manager. llvm-svn: 261624
2016-02-23 18:02:02 +08:00
EXPECT_EQ(14, AnalyzedInstrCount1);
EXPECT_EQ(6, AnalyzedSCCFunctionCount1);
EXPECT_EQ(4 * 6, AnalyzedModuleFunctionCount1);
}
[PM] Add a unittest for invalidating module analyses with an SCC pass. This reinstates r280447. Original commit log: This wasn't really well explicitly tested with a nice unittest before. It seems good to have reasonably broken out unittests for this kind of functionality as I'm workin go other invalidation features to make sure none of the existing ones regress. This still has too much duplicated code, I plan to factor that out in a subsequent commit to use common helpers for repeated parts of this. llvm-svn: 282377
2016-09-26 12:01:55 +08:00
// Test that an SCC pass which fails to preserve a module analysis does in fact
// invalidate that module analysis.
TEST_F(CGSCCPassManagerTest, TestSCCPassInvalidatesModuleAnalysis) {
int ModuleAnalysisRuns = 0;
MAM.registerPass([&] { return TestModuleAnalysis(ModuleAnalysisRuns); });
ModulePassManager MPM(/*DebugLogging*/ true);
MPM.addPass(RequireAnalysisPass<TestModuleAnalysis, Module>());
// The first CGSCC run we preserve everything and make sure that works and
// the module analysis is available in the second CGSCC run from the one
// required module pass above.
CGSCCPassManager CGPM1(/*DebugLogging*/ true);
int CountFoundModuleAnalysis1 = 0;
CGPM1.addPass(
LambdaSCCPass([&](LazyCallGraph::SCC &C, CGSCCAnalysisManager &AM,
LazyCallGraph &CG, CGSCCUpdateResult &UR) {
const auto &MAM =
AM.getResult<ModuleAnalysisManagerCGSCCProxy>(C, CG).getManager();
auto *TMA = MAM.getCachedResult<TestModuleAnalysis>(
*C.begin()->getFunction().getParent());
if (TMA)
++CountFoundModuleAnalysis1;
return PreservedAnalyses::all();
}));
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM1)));
// The second CGSCC run checks that the module analysis got preserved the
// previous time and in one SCC fails to preserve it.
CGSCCPassManager CGPM2(/*DebugLogging*/ true);
int CountFoundModuleAnalysis2 = 0;
CGPM2.addPass(
LambdaSCCPass([&](LazyCallGraph::SCC &C, CGSCCAnalysisManager &AM,
LazyCallGraph &CG, CGSCCUpdateResult &UR) {
const auto &MAM =
AM.getResult<ModuleAnalysisManagerCGSCCProxy>(C, CG).getManager();
auto *TMA = MAM.getCachedResult<TestModuleAnalysis>(
*C.begin()->getFunction().getParent());
if (TMA)
++CountFoundModuleAnalysis2;
// Only fail to preserve analyses on one SCC and make sure that gets
// propagated.
return C.getName() == "(g)" ? PreservedAnalyses::none()
: PreservedAnalyses::all();
}));
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM2)));
// The third CGSCC run should fail to find a cached module analysis as it
// should have been invalidated by the above CGSCC run.
CGSCCPassManager CGPM3(/*DebugLogging*/ true);
int CountFoundModuleAnalysis3 = 0;
CGPM3.addPass(
LambdaSCCPass([&](LazyCallGraph::SCC &C, CGSCCAnalysisManager &AM,
LazyCallGraph &CG, CGSCCUpdateResult &UR) {
const auto &MAM =
AM.getResult<ModuleAnalysisManagerCGSCCProxy>(C, CG).getManager();
auto *TMA = MAM.getCachedResult<TestModuleAnalysis>(
*C.begin()->getFunction().getParent());
if (TMA)
++CountFoundModuleAnalysis3;
return PreservedAnalyses::none();
}));
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM3)));
MPM.run(*M, MAM);
EXPECT_EQ(1, ModuleAnalysisRuns);
EXPECT_EQ(4, CountFoundModuleAnalysis1);
EXPECT_EQ(4, CountFoundModuleAnalysis2);
EXPECT_EQ(0, CountFoundModuleAnalysis3);
}
[PM] Add a unittest covering the invalidation of a Module analysis from a function pass nested inside of a CGSCC pass manager. This is very similar to the previous unittest but makes sure the invalidation logic works across all the layers here. llvm-svn: 282378
2016-09-26 12:17:12 +08:00
// Similar to the above, but test that this works for function passes embedded
// *within* a CGSCC layer.
TEST_F(CGSCCPassManagerTest, TestFunctionPassInsideCGSCCInvalidatesModuleAnalysis) {
int ModuleAnalysisRuns = 0;
MAM.registerPass([&] { return TestModuleAnalysis(ModuleAnalysisRuns); });
ModulePassManager MPM(/*DebugLogging*/ true);
MPM.addPass(RequireAnalysisPass<TestModuleAnalysis, Module>());
// The first run we preserve everything and make sure that works and the
// module analysis is available in the second run from the one required
// module pass above.
FunctionPassManager FPM1(/*DebugLogging*/ true);
// Start true and mark false if we ever failed to find a module analysis
// because we expect this to succeed for each SCC.
bool FoundModuleAnalysis1 = true;
FPM1.addPass(
LambdaFunctionPass([&](Function &F, FunctionAnalysisManager &AM) {
const auto &MAM =
AM.getResult<ModuleAnalysisManagerFunctionProxy>(F).getManager();
auto *TMA = MAM.getCachedResult<TestModuleAnalysis>(*F.getParent());
if (!TMA)
FoundModuleAnalysis1 = false;
return PreservedAnalyses::all();
}));
CGSCCPassManager CGPM1(/*DebugLogging*/ true);
CGPM1.addPass(createCGSCCToFunctionPassAdaptor(std::move(FPM1)));
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM1)));
// The second run checks that the module analysis got preserved the previous
// time and in one function fails to preserve it.
FunctionPassManager FPM2(/*DebugLogging*/ true);
// Again, start true and mark false if we ever failed to find a module analysis
// because we expect this to succeed for each SCC.
bool FoundModuleAnalysis2 = true;
FPM2.addPass(
LambdaFunctionPass([&](Function &F, FunctionAnalysisManager &AM) {
const auto &MAM =
AM.getResult<ModuleAnalysisManagerFunctionProxy>(F).getManager();
auto *TMA = MAM.getCachedResult<TestModuleAnalysis>(*F.getParent());
if (!TMA)
FoundModuleAnalysis2 = false;
// Only fail to preserve analyses on one SCC and make sure that gets
// propagated.
return F.getName() == "h2" ? PreservedAnalyses::none()
: PreservedAnalyses::all();
}));
CGSCCPassManager CGPM2(/*DebugLogging*/ true);
CGPM2.addPass(createCGSCCToFunctionPassAdaptor(std::move(FPM2)));
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM2)));
// The third run should fail to find a cached module analysis as it should
// have been invalidated by the above run.
FunctionPassManager FPM3(/*DebugLogging*/ true);
// Start false and mark true if we ever *succeeded* to find a module
// analysis, as we expect this to fail for every function.
bool FoundModuleAnalysis3 = false;
FPM3.addPass(
LambdaFunctionPass([&](Function &F, FunctionAnalysisManager &AM) {
const auto &MAM =
AM.getResult<ModuleAnalysisManagerFunctionProxy>(F).getManager();
auto *TMA = MAM.getCachedResult<TestModuleAnalysis>(*F.getParent());
if (TMA)
FoundModuleAnalysis3 = true;
return PreservedAnalyses::none();
}));
CGSCCPassManager CGPM3(/*DebugLogging*/ true);
CGPM3.addPass(createCGSCCToFunctionPassAdaptor(std::move(FPM3)));
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM3)));
MPM.run(*M, MAM);
EXPECT_EQ(1, ModuleAnalysisRuns);
EXPECT_TRUE(FoundModuleAnalysis1);
EXPECT_TRUE(FoundModuleAnalysis2);
EXPECT_FALSE(FoundModuleAnalysis3);
}
[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 14:34:44 +08:00
// Test that a Module pass which fails to preserve an SCC analysis in fact
// invalidates that analysis.
TEST_F(CGSCCPassManagerTest, TestModulePassInvalidatesSCCAnalysis) {
int SCCAnalysisRuns = 0;
CGAM.registerPass([&] { return TestSCCAnalysis(SCCAnalysisRuns); });
ModulePassManager MPM(/*DebugLogging*/ true);
// First force the analysis to be run.
CGSCCPassManager CGPM1(/*DebugLogging*/ true);
CGPM1.addPass(RequireAnalysisPass<TestSCCAnalysis, LazyCallGraph::SCC,
CGSCCAnalysisManager, LazyCallGraph &,
CGSCCUpdateResult &>());
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM1)));
// Now run a module pass that preserves the LazyCallGraph and the proxy but
// not the SCC analysis.
MPM.addPass(LambdaModulePass([&](Module &M, ModuleAnalysisManager &) {
PreservedAnalyses PA;
PA.preserve<LazyCallGraphAnalysis>();
PA.preserve<CGSCCAnalysisManagerModuleProxy>();
PA.preserve<FunctionAnalysisManagerModuleProxy>();
return PA;
}));
// And now a second CGSCC run which requires the SCC analysis again. This
// will trigger re-running it.
CGSCCPassManager CGPM2(/*DebugLogging*/ true);
CGPM2.addPass(RequireAnalysisPass<TestSCCAnalysis, LazyCallGraph::SCC,
CGSCCAnalysisManager, LazyCallGraph &,
CGSCCUpdateResult &>());
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM2)));
MPM.run(*M, MAM);
// Two runs and four SCCs.
EXPECT_EQ(2 * 4, SCCAnalysisRuns);
}
// Check that marking the SCC analysis preserved is sufficient to avoid
// invaliadtion. This should only run the analysis once for each SCC.
TEST_F(CGSCCPassManagerTest, TestModulePassCanPreserveSCCAnalysis) {
int SCCAnalysisRuns = 0;
CGAM.registerPass([&] { return TestSCCAnalysis(SCCAnalysisRuns); });
ModulePassManager MPM(/*DebugLogging*/ true);
// First force the analysis to be run.
CGSCCPassManager CGPM1(/*DebugLogging*/ true);
CGPM1.addPass(RequireAnalysisPass<TestSCCAnalysis, LazyCallGraph::SCC,
CGSCCAnalysisManager, LazyCallGraph &,
CGSCCUpdateResult &>());
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM1)));
// Now run a module pass that preserves each of the necessary components
// (but not everything).
MPM.addPass(LambdaModulePass([&](Module &M, ModuleAnalysisManager &) {
PreservedAnalyses PA;
PA.preserve<LazyCallGraphAnalysis>();
PA.preserve<CGSCCAnalysisManagerModuleProxy>();
PA.preserve<FunctionAnalysisManagerModuleProxy>();
PA.preserve<TestSCCAnalysis>();
return PA;
}));
// And now a second CGSCC run which requires the SCC analysis again but find
// it in the cache.
CGSCCPassManager CGPM2(/*DebugLogging*/ true);
CGPM2.addPass(RequireAnalysisPass<TestSCCAnalysis, LazyCallGraph::SCC,
CGSCCAnalysisManager, LazyCallGraph &,
CGSCCUpdateResult &>());
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM2)));
MPM.run(*M, MAM);
// Four SCCs
EXPECT_EQ(4, SCCAnalysisRuns);
}
// Check that even when the analysis is preserved, if the SCC information isn't
// we still nuke things because the SCC keys could change.
TEST_F(CGSCCPassManagerTest, TestModulePassInvalidatesSCCAnalysisOnCGChange) {
int SCCAnalysisRuns = 0;
CGAM.registerPass([&] { return TestSCCAnalysis(SCCAnalysisRuns); });
ModulePassManager MPM(/*DebugLogging*/ true);
// First force the analysis to be run.
CGSCCPassManager CGPM1(/*DebugLogging*/ true);
CGPM1.addPass(RequireAnalysisPass<TestSCCAnalysis, LazyCallGraph::SCC,
CGSCCAnalysisManager, LazyCallGraph &,
CGSCCUpdateResult &>());
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM1)));
// Now run a module pass that preserves the analysis but not the call
// graph or proxy.
MPM.addPass(LambdaModulePass([&](Module &M, ModuleAnalysisManager &) {
PreservedAnalyses PA;
PA.preserve<TestSCCAnalysis>();
return PA;
}));
// And now a second CGSCC run which requires the SCC analysis again.
CGSCCPassManager CGPM2(/*DebugLogging*/ true);
CGPM2.addPass(RequireAnalysisPass<TestSCCAnalysis, LazyCallGraph::SCC,
CGSCCAnalysisManager, LazyCallGraph &,
CGSCCUpdateResult &>());
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM2)));
MPM.run(*M, MAM);
// Two runs and four SCCs.
EXPECT_EQ(2 * 4, SCCAnalysisRuns);
}
// Test that an SCC pass which fails to preserve a Function analysis in fact
// invalidates that analysis.
TEST_F(CGSCCPassManagerTest, TestSCCPassInvalidatesFunctionAnalysis) {
int FunctionAnalysisRuns = 0;
FAM.registerPass([&] { return TestFunctionAnalysis(FunctionAnalysisRuns); });
// Create a very simple module with a single function and SCC to make testing
// these issues much easier.
std::unique_ptr<Module> M = parseIR("declare void @g()\n"
"declare void @h()\n"
"define void @f() {\n"
"entry:\n"
" call void @g()\n"
" call void @h()\n"
" ret void\n"
"}\n");
CGSCCPassManager CGPM(/*DebugLogging*/ true);
// First force the analysis to be run.
FunctionPassManager FPM1(/*DebugLogging*/ true);
FPM1.addPass(RequireAnalysisPass<TestFunctionAnalysis, Function>());
CGPM.addPass(createCGSCCToFunctionPassAdaptor(std::move(FPM1)));
// Now run a module pass that preserves the LazyCallGraph and proxy but not
// the SCC analysis.
CGPM.addPass(LambdaSCCPass([&](LazyCallGraph::SCC &C, CGSCCAnalysisManager &,
LazyCallGraph &, CGSCCUpdateResult &) {
PreservedAnalyses PA;
PA.preserve<LazyCallGraphAnalysis>();
return PA;
}));
// And now a second CGSCC run which requires the SCC analysis again. This
// will trigger re-running it.
FunctionPassManager FPM2(/*DebugLogging*/ true);
FPM2.addPass(RequireAnalysisPass<TestFunctionAnalysis, Function>());
CGPM.addPass(createCGSCCToFunctionPassAdaptor(std::move(FPM2)));
ModulePassManager MPM(/*DebugLogging*/ true);
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM)));
MPM.run(*M, MAM);
EXPECT_EQ(2, FunctionAnalysisRuns);
}
// Check that marking the SCC analysis preserved is sufficient. This should
// only run the analysis once the SCC.
TEST_F(CGSCCPassManagerTest, TestSCCPassCanPreserveFunctionAnalysis) {
int FunctionAnalysisRuns = 0;
FAM.registerPass([&] { return TestFunctionAnalysis(FunctionAnalysisRuns); });
// Create a very simple module with a single function and SCC to make testing
// these issues much easier.
std::unique_ptr<Module> M = parseIR("declare void @g()\n"
"declare void @h()\n"
"define void @f() {\n"
"entry:\n"
" call void @g()\n"
" call void @h()\n"
" ret void\n"
"}\n");
CGSCCPassManager CGPM(/*DebugLogging*/ true);
// First force the analysis to be run.
FunctionPassManager FPM1(/*DebugLogging*/ true);
FPM1.addPass(RequireAnalysisPass<TestFunctionAnalysis, Function>());
CGPM.addPass(createCGSCCToFunctionPassAdaptor(std::move(FPM1)));
// Now run a module pass that preserves each of the necessary components
// (but
// not everything).
CGPM.addPass(LambdaSCCPass([&](LazyCallGraph::SCC &C, CGSCCAnalysisManager &,
LazyCallGraph &, CGSCCUpdateResult &) {
PreservedAnalyses PA;
PA.preserve<LazyCallGraphAnalysis>();
PA.preserve<TestFunctionAnalysis>();
return PA;
}));
// And now a second CGSCC run which requires the SCC analysis again but find
// it in the cache.
FunctionPassManager FPM2(/*DebugLogging*/ true);
FPM2.addPass(RequireAnalysisPass<TestFunctionAnalysis, Function>());
CGPM.addPass(createCGSCCToFunctionPassAdaptor(std::move(FPM2)));
ModulePassManager MPM(/*DebugLogging*/ true);
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM)));
MPM.run(*M, MAM);
EXPECT_EQ(1, FunctionAnalysisRuns);
}
// Note that there is no test for invalidating the call graph or other
// structure with an SCC pass because there is no mechanism to do that from
// withinsuch a pass. Instead, such a pass has to directly update the call
// graph structure.
// Test that a madule pass invalidates function analyses when the CGSCC proxies
// and pass manager.
TEST_F(CGSCCPassManagerTest,
TestModulePassInvalidatesFunctionAnalysisNestedInCGSCC) {
MAM.registerPass([&] { return LazyCallGraphAnalysis(); });
int FunctionAnalysisRuns = 0;
FAM.registerPass([&] { return TestFunctionAnalysis(FunctionAnalysisRuns); });
ModulePassManager MPM(/*DebugLogging*/ true);
// First force the analysis to be run.
FunctionPassManager FPM1(/*DebugLogging*/ true);
FPM1.addPass(RequireAnalysisPass<TestFunctionAnalysis, Function>());
CGSCCPassManager CGPM1(/*DebugLogging*/ true);
CGPM1.addPass(createCGSCCToFunctionPassAdaptor(std::move(FPM1)));
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM1)));
// Now run a module pass that preserves the LazyCallGraph and proxy but not
// the Function analysis.
MPM.addPass(LambdaModulePass([&](Module &M, ModuleAnalysisManager &) {
PreservedAnalyses PA;
PA.preserve<LazyCallGraphAnalysis>();
PA.preserve<CGSCCAnalysisManagerModuleProxy>();
return PA;
}));
// And now a second CGSCC run which requires the SCC analysis again. This
// will trigger re-running it.
FunctionPassManager FPM2(/*DebugLogging*/ true);
FPM2.addPass(RequireAnalysisPass<TestFunctionAnalysis, Function>());
CGSCCPassManager CGPM2(/*DebugLogging*/ true);
CGPM2.addPass(createCGSCCToFunctionPassAdaptor(std::move(FPM2)));
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM2)));
MPM.run(*M, MAM);
// Two runs and 6 functions.
EXPECT_EQ(2 * 6, FunctionAnalysisRuns);
}
// Check that by marking the function pass and FAM proxy as preserved, this
// propagates all the way through.
TEST_F(CGSCCPassManagerTest,
TestModulePassCanPreserveFunctionAnalysisNestedInCGSCC) {
MAM.registerPass([&] { return LazyCallGraphAnalysis(); });
int FunctionAnalysisRuns = 0;
FAM.registerPass([&] { return TestFunctionAnalysis(FunctionAnalysisRuns); });
ModulePassManager MPM(/*DebugLogging*/ true);
// First force the analysis to be run.
FunctionPassManager FPM1(/*DebugLogging*/ true);
FPM1.addPass(RequireAnalysisPass<TestFunctionAnalysis, Function>());
CGSCCPassManager CGPM1(/*DebugLogging*/ true);
CGPM1.addPass(createCGSCCToFunctionPassAdaptor(std::move(FPM1)));
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM1)));
// Now run a module pass that preserves the LazyCallGraph, the proxy, and
// the Function analysis.
MPM.addPass(LambdaModulePass([&](Module &M, ModuleAnalysisManager &) {
PreservedAnalyses PA;
PA.preserve<LazyCallGraphAnalysis>();
PA.preserve<CGSCCAnalysisManagerModuleProxy>();
PA.preserve<FunctionAnalysisManagerModuleProxy>();
PA.preserve<TestFunctionAnalysis>();
return PA;
}));
// And now a second CGSCC run which requires the SCC analysis again. This
// will trigger re-running it.
FunctionPassManager FPM2(/*DebugLogging*/ true);
FPM2.addPass(RequireAnalysisPass<TestFunctionAnalysis, Function>());
CGSCCPassManager CGPM2(/*DebugLogging*/ true);
CGPM2.addPass(createCGSCCToFunctionPassAdaptor(std::move(FPM2)));
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM2)));
MPM.run(*M, MAM);
// One run and 6 functions.
EXPECT_EQ(6, FunctionAnalysisRuns);
}
// Check that if the lazy call graph itself isn't preserved we still manage to
// invalidate everything.
TEST_F(CGSCCPassManagerTest,
TestModulePassInvalidatesFunctionAnalysisNestedInCGSCCOnCGChange) {
MAM.registerPass([&] { return LazyCallGraphAnalysis(); });
int FunctionAnalysisRuns = 0;
FAM.registerPass([&] { return TestFunctionAnalysis(FunctionAnalysisRuns); });
ModulePassManager MPM(/*DebugLogging*/ true);
// First force the analysis to be run.
FunctionPassManager FPM1(/*DebugLogging*/ true);
FPM1.addPass(RequireAnalysisPass<TestFunctionAnalysis, Function>());
CGSCCPassManager CGPM1(/*DebugLogging*/ true);
CGPM1.addPass(createCGSCCToFunctionPassAdaptor(std::move(FPM1)));
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM1)));
// Now run a module pass that preserves the LazyCallGraph but not the
// Function analysis.
MPM.addPass(LambdaModulePass([&](Module &M, ModuleAnalysisManager &) {
PreservedAnalyses PA;
return PA;
}));
// And now a second CGSCC run which requires the SCC analysis again. This
// will trigger re-running it.
FunctionPassManager FPM2(/*DebugLogging*/ true);
FPM2.addPass(RequireAnalysisPass<TestFunctionAnalysis, Function>());
CGSCCPassManager CGPM2(/*DebugLogging*/ true);
CGPM2.addPass(createCGSCCToFunctionPassAdaptor(std::move(FPM2)));
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM2)));
MPM.run(*M, MAM);
// Two runs and 6 functions.
EXPECT_EQ(2 * 6, FunctionAnalysisRuns);
}
[PM] Introduce the facilities for registering cross-IR-unit dependencies that require deferred invalidation. This handles the other real-world invalidation scenario that we have cases of: a function analysis which caches references to a module analysis. We currently do this in the AA aggregation layer and might well do this in other places as well. Since this is relative rare, the technique is somewhat more cumbersome. Analyses need to register themselves when accessing the outer analysis manager's proxy. This proxy is already necessarily present to allow access to the outer IR unit's analyses. By registering here we can track and trigger invalidation when that outer analysis goes away. To make this work we need to enhance the PreservedAnalyses infrastructure to support a (slightly) more explicit model for "sets" of analyses, and allow abandoning a single specific analyses even when a set covering that analysis is preserved. That allows us to describe the scenario of preserving all Function analyses *except* for the one where deferred invalidation has triggered. We also need to teach the invalidator API to support direct ID calls instead of always going through a template to dispatch so that we can just record the ID mapping. I've introduced testing of all of this both for simple module<->function cases as well as for more complex cases involving a CGSCC layer. Much like the previous patch I've not tried to fully update the loop pass management layer because that layer is due to be heavily reworked to use similar techniques to the CGSCC to handle updates. As that happens, we'll have a better testing basis for adding support like this. Many thanks to both Justin and Sean for the extensive reviews on this to help bring the API design and documentation into a better state. Differential Revision: https://reviews.llvm.org/D27198 llvm-svn: 290594
2016-12-27 16:40:39 +08:00
/// A test CGSCC-level analysis pass which caches in its result another
/// analysis pass and uses it to serve queries. This requires the result to
/// invalidate itself when its dependency is invalidated.
///
/// FIXME: Currently this doesn't also depend on a function analysis, and if it
/// did we would fail to invalidate it correctly.
struct TestIndirectSCCAnalysis
: public AnalysisInfoMixin<TestIndirectSCCAnalysis> {
struct Result {
Result(TestSCCAnalysis::Result &SCCDep, TestModuleAnalysis::Result &MDep)
: SCCDep(SCCDep), MDep(MDep) {}
TestSCCAnalysis::Result &SCCDep;
TestModuleAnalysis::Result &MDep;
bool invalidate(LazyCallGraph::SCC &C, const PreservedAnalyses &PA,
CGSCCAnalysisManager::Invalidator &Inv) {
auto PAC = PA.getChecker<TestIndirectSCCAnalysis>();
return !(PAC.preserved() ||
PAC.preservedSet<AllAnalysesOn<LazyCallGraph::SCC>>()) ||
Inv.invalidate<TestSCCAnalysis>(C, PA);
}
};
TestIndirectSCCAnalysis(int &Runs) : Runs(Runs) {}
/// Run the analysis pass over the function and return a result.
Result run(LazyCallGraph::SCC &C, CGSCCAnalysisManager &AM,
LazyCallGraph &CG) {
++Runs;
auto &SCCDep = AM.getResult<TestSCCAnalysis>(C, CG);
auto &ModuleProxy = AM.getResult<ModuleAnalysisManagerCGSCCProxy>(C, CG);
const ModuleAnalysisManager &MAM = ModuleProxy.getManager();
// For the test, we insist that the module analysis starts off in the
// cache.
auto &MDep = *MAM.getCachedResult<TestModuleAnalysis>(
*C.begin()->getFunction().getParent());
// Register the dependency as module analysis dependencies have to be
// pre-registered on the proxy.
ModuleProxy.registerOuterAnalysisInvalidation<TestModuleAnalysis,
TestIndirectSCCAnalysis>();
return Result(SCCDep, MDep);
}
private:
friend AnalysisInfoMixin<TestIndirectSCCAnalysis>;
static AnalysisKey Key;
int &Runs;
};
AnalysisKey TestIndirectSCCAnalysis::Key;
/// A test analysis pass which caches in its result the result from the above
/// indirect analysis pass.
///
/// This allows us to ensure that whenever an analysis pass is invalidated due
/// to dependencies (especially dependencies across IR units that trigger
/// asynchronous invalidation) we correctly detect that this may in turn cause
/// other analysis to be invalidated.
struct TestDoublyIndirectSCCAnalysis
: public AnalysisInfoMixin<TestDoublyIndirectSCCAnalysis> {
struct Result {
Result(TestIndirectSCCAnalysis::Result &IDep) : IDep(IDep) {}
TestIndirectSCCAnalysis::Result &IDep;
bool invalidate(LazyCallGraph::SCC &C, const PreservedAnalyses &PA,
CGSCCAnalysisManager::Invalidator &Inv) {
auto PAC = PA.getChecker<TestDoublyIndirectSCCAnalysis>();
return !(PAC.preserved() ||
PAC.preservedSet<AllAnalysesOn<LazyCallGraph::SCC>>()) ||
Inv.invalidate<TestIndirectSCCAnalysis>(C, PA);
}
};
TestDoublyIndirectSCCAnalysis(int &Runs) : Runs(Runs) {}
/// Run the analysis pass over the function and return a result.
Result run(LazyCallGraph::SCC &C, CGSCCAnalysisManager &AM,
LazyCallGraph &CG) {
++Runs;
auto &IDep = AM.getResult<TestIndirectSCCAnalysis>(C, CG);
return Result(IDep);
}
private:
friend AnalysisInfoMixin<TestDoublyIndirectSCCAnalysis>;
static AnalysisKey Key;
int &Runs;
};
AnalysisKey TestDoublyIndirectSCCAnalysis::Key;
/// A test analysis pass which caches results from three different IR unit
/// layers and requires intermediate layers to correctly propagate the entire
/// distance.
struct TestIndirectFunctionAnalysis
: public AnalysisInfoMixin<TestIndirectFunctionAnalysis> {
struct Result {
Result(TestFunctionAnalysis::Result &FDep, TestModuleAnalysis::Result &MDep,
TestSCCAnalysis::Result &SCCDep)
: FDep(FDep), MDep(MDep), SCCDep(SCCDep) {}
TestFunctionAnalysis::Result &FDep;
TestModuleAnalysis::Result &MDep;
TestSCCAnalysis::Result &SCCDep;
bool invalidate(Function &F, const PreservedAnalyses &PA,
FunctionAnalysisManager::Invalidator &Inv) {
auto PAC = PA.getChecker<TestIndirectFunctionAnalysis>();
return !(PAC.preserved() ||
PAC.preservedSet<AllAnalysesOn<Function>>()) ||
Inv.invalidate<TestFunctionAnalysis>(F, PA);
}
};
TestIndirectFunctionAnalysis(int &Runs) : Runs(Runs) {}
/// Run the analysis pass over the function and return a result.
Result run(Function &F, FunctionAnalysisManager &AM) {
++Runs;
auto &FDep = AM.getResult<TestFunctionAnalysis>(F);
auto &ModuleProxy = AM.getResult<ModuleAnalysisManagerFunctionProxy>(F);
const ModuleAnalysisManager &MAM = ModuleProxy.getManager();
// For the test, we insist that the module analysis starts off in the
// cache.
auto &MDep = *MAM.getCachedResult<TestModuleAnalysis>(*F.getParent());
// Register the dependency as module analysis dependencies have to be
// pre-registered on the proxy.
ModuleProxy.registerOuterAnalysisInvalidation<
TestModuleAnalysis, TestIndirectFunctionAnalysis>();
// For thet test we assume this is run inside a CGSCC pass manager.
const LazyCallGraph &CG =
*MAM.getCachedResult<LazyCallGraphAnalysis>(*F.getParent());
auto &CGSCCProxy = AM.getResult<CGSCCAnalysisManagerFunctionProxy>(F);
const CGSCCAnalysisManager &CGAM = CGSCCProxy.getManager();
// For the test, we insist that the CGSCC analysis starts off in the cache.
auto &SCCDep =
*CGAM.getCachedResult<TestSCCAnalysis>(*CG.lookupSCC(*CG.lookup(F)));
// Register the dependency as CGSCC analysis dependencies have to be
// pre-registered on the proxy.
CGSCCProxy.registerOuterAnalysisInvalidation<
TestSCCAnalysis, TestIndirectFunctionAnalysis>();
return Result(FDep, MDep, SCCDep);
}
private:
friend AnalysisInfoMixin<TestIndirectFunctionAnalysis>;
static AnalysisKey Key;
int &Runs;
};
AnalysisKey TestIndirectFunctionAnalysis::Key;
TEST_F(CGSCCPassManagerTest, TestIndirectAnalysisInvalidation) {
int ModuleAnalysisRuns = 0;
MAM.registerPass([&] { return TestModuleAnalysis(ModuleAnalysisRuns); });
int SCCAnalysisRuns = 0, IndirectSCCAnalysisRuns = 0,
DoublyIndirectSCCAnalysisRuns = 0;
CGAM.registerPass([&] { return TestSCCAnalysis(SCCAnalysisRuns); });
CGAM.registerPass(
[&] { return TestIndirectSCCAnalysis(IndirectSCCAnalysisRuns); });
CGAM.registerPass([&] {
return TestDoublyIndirectSCCAnalysis(DoublyIndirectSCCAnalysisRuns);
});
int FunctionAnalysisRuns = 0, IndirectFunctionAnalysisRuns = 0;
FAM.registerPass([&] { return TestFunctionAnalysis(FunctionAnalysisRuns); });
FAM.registerPass([&] {
return TestIndirectFunctionAnalysis(IndirectFunctionAnalysisRuns);
});
ModulePassManager MPM(/*DebugLogging*/ true);
int FunctionCount = 0;
CGSCCPassManager CGPM(/*DebugLogging*/ true);
// First just use the analysis to get the function count and preserve
// everything.
CGPM.addPass(
LambdaSCCPass([&](LazyCallGraph::SCC &C, CGSCCAnalysisManager &AM,
LazyCallGraph &CG, CGSCCUpdateResult &) {
auto &DoublyIndirectResult =
AM.getResult<TestDoublyIndirectSCCAnalysis>(C, CG);
auto &IndirectResult = DoublyIndirectResult.IDep;
FunctionCount += IndirectResult.SCCDep.FunctionCount;
return PreservedAnalyses::all();
}));
// Next, invalidate
// - both analyses for the (f) and (x) SCCs,
// - just the underlying (indirect) analysis for (g) SCC, and
// - just the direct analysis for (h1,h2,h3) SCC.
CGPM.addPass(
LambdaSCCPass([&](LazyCallGraph::SCC &C, CGSCCAnalysisManager &AM,
LazyCallGraph &CG, CGSCCUpdateResult &) {
auto &DoublyIndirectResult =
AM.getResult<TestDoublyIndirectSCCAnalysis>(C, CG);
auto &IndirectResult = DoublyIndirectResult.IDep;
FunctionCount += IndirectResult.SCCDep.FunctionCount;
auto PA = PreservedAnalyses::none();
if (C.getName() == "(g)")
PA.preserve<TestSCCAnalysis>();
else if (C.getName() == "(h3, h1, h2)")
PA.preserve<TestIndirectSCCAnalysis>();
return PA;
}));
// Finally, use the analysis again on each function, forcing re-computation
// for all of them.
CGPM.addPass(
LambdaSCCPass([&](LazyCallGraph::SCC &C, CGSCCAnalysisManager &AM,
LazyCallGraph &CG, CGSCCUpdateResult &) {
auto &DoublyIndirectResult =
AM.getResult<TestDoublyIndirectSCCAnalysis>(C, CG);
auto &IndirectResult = DoublyIndirectResult.IDep;
FunctionCount += IndirectResult.SCCDep.FunctionCount;
return PreservedAnalyses::all();
}));
// Create a second CGSCC pass manager. This will cause the module-level
// invalidation to occur, which will force yet another invalidation of the
// indirect SCC-level analysis as the module analysis it depends on gets
// invalidated.
CGSCCPassManager CGPM2(/*DebugLogging*/ true);
CGPM2.addPass(
LambdaSCCPass([&](LazyCallGraph::SCC &C, CGSCCAnalysisManager &AM,
LazyCallGraph &CG, CGSCCUpdateResult &) {
auto &DoublyIndirectResult =
AM.getResult<TestDoublyIndirectSCCAnalysis>(C, CG);
auto &IndirectResult = DoublyIndirectResult.IDep;
FunctionCount += IndirectResult.SCCDep.FunctionCount;
return PreservedAnalyses::all();
}));
// Add a requires pass to populate the module analysis and then our function
// pass pipeline.
MPM.addPass(RequireAnalysisPass<TestModuleAnalysis, Module>());
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM)));
// Now require the module analysis again (it will have been invalidated once)
// and then use it again from a function pass manager.
MPM.addPass(RequireAnalysisPass<TestModuleAnalysis, Module>());
MPM.addPass(createModuleToPostOrderCGSCCPassAdaptor(std::move(CGPM2)));
MPM.run(*M, MAM);
// There are generally two possible runs for each of the four SCCs. But
// for one SCC, we only invalidate the indirect analysis so the base one
// only gets run seven times.
EXPECT_EQ(7, SCCAnalysisRuns);
// The module analysis pass should be run twice here.
EXPECT_EQ(2, ModuleAnalysisRuns);
// The indirect analysis is invalidated (either directly or indirectly) three
// times for each of four SCCs.
EXPECT_EQ(3 * 4, IndirectSCCAnalysisRuns);
EXPECT_EQ(3 * 4, DoublyIndirectSCCAnalysisRuns);
// Four passes count each of six functions once (via SCCs).
EXPECT_EQ(4 * 6, FunctionCount);
}
[PM] Add a unittest for the CGSCC pass manager in the new pass manager system. Previously, this was only being tested with larger integration tests. That makes it hard to isolated specific issues with it, and makes the APIs themselves less well tested. Add a unittest based around the same patterns used for testing the general pass manager. llvm-svn: 261624
2016-02-23 18:02:02 +08:00
}