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/LazyCallGraphTest.cpp

721 lines
22 KiB
C++
Raw Normal View History

[LCG] Add a unittest for the LazyCallGraph. I had a weak moment and resisted this for too long. Just with the basic testing here I was able to exercise the analysis in more detail and sift out both type signature bugs in the API and a bug in the DFS numbering. All of these are fixed here as well. The unittests will be much more important for the mutation support where it is necessary to craft minimal mutations and then inspect the state of the graph. There is just no way to do that with a standard FileCheck test. However, unittesting these kinds of analyses is really quite easy, especially as they're designed with the new pass manager where there is essentially no infrastructure required to rig up the core logic and exercise it at an API level. As a minor aside about the DFS numbering bug, the DFS numbering used in LCG is a bit unusual. Rather than numbering from 0, we number from 1, and use 0 as the sentinel "unvisited" state. Other implementations often use '-1' for this, but I find it easier to deal with 0 and it shouldn't make any real difference provided someone doesn't write silly bugs like forgetting to actually initialize the DFS numbering. Oops. ;] llvm-svn: 206954
2014-04-23 16:08:49 +08:00
//===- LazyCallGraphTest.cpp - Unit tests for the lazy CG analysis --------===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
#include "llvm/Analysis/LazyCallGraph.h"
#include "llvm/AsmParser/Parser.h"
#include "llvm/IR/Function.h"
#include "llvm/IR/LLVMContext.h"
#include "llvm/IR/Module.h"
#include "llvm/Support/ErrorHandling.h"
#include "llvm/Support/SourceMgr.h"
#include "gtest/gtest.h"
#include <memory>
using namespace llvm;
namespace {
std::unique_ptr<Module> parseAssembly(const char *Assembly) {
SMDiagnostic Error;
Modernize the .ll parsing interface. * Use StringRef instead of std::string& * Return a std::unique_ptr<Module> instead of taking an optional module to write to (was not really used). * Use current comment style. * Use current naming convention. llvm-svn: 215989
2014-08-20 00:58:54 +08:00
std::unique_ptr<Module> M =
parseAssemblyString(Assembly, Error, getGlobalContext());
[LCG] Add a unittest for the LazyCallGraph. I had a weak moment and resisted this for too long. Just with the basic testing here I was able to exercise the analysis in more detail and sift out both type signature bugs in the API and a bug in the DFS numbering. All of these are fixed here as well. The unittests will be much more important for the mutation support where it is necessary to craft minimal mutations and then inspect the state of the graph. There is just no way to do that with a standard FileCheck test. However, unittesting these kinds of analyses is really quite easy, especially as they're designed with the new pass manager where there is essentially no infrastructure required to rig up the core logic and exercise it at an API level. As a minor aside about the DFS numbering bug, the DFS numbering used in LCG is a bit unusual. Rather than numbering from 0, we number from 1, and use 0 as the sentinel "unvisited" state. Other implementations often use '-1' for this, but I find it easier to deal with 0 and it shouldn't make any real difference provided someone doesn't write silly bugs like forgetting to actually initialize the DFS numbering. Oops. ;] llvm-svn: 206954
2014-04-23 16:08:49 +08:00
std::string ErrMsg;
raw_string_ostream OS(ErrMsg);
Error.print("", OS);
// A failure here means that the test itself is buggy.
Modernize the .ll parsing interface. * Use StringRef instead of std::string& * Return a std::unique_ptr<Module> instead of taking an optional module to write to (was not really used). * Use current comment style. * Use current naming convention. llvm-svn: 215989
2014-08-20 00:58:54 +08:00
if (!M)
[LCG] Add a unittest for the LazyCallGraph. I had a weak moment and resisted this for too long. Just with the basic testing here I was able to exercise the analysis in more detail and sift out both type signature bugs in the API and a bug in the DFS numbering. All of these are fixed here as well. The unittests will be much more important for the mutation support where it is necessary to craft minimal mutations and then inspect the state of the graph. There is just no way to do that with a standard FileCheck test. However, unittesting these kinds of analyses is really quite easy, especially as they're designed with the new pass manager where there is essentially no infrastructure required to rig up the core logic and exercise it at an API level. As a minor aside about the DFS numbering bug, the DFS numbering used in LCG is a bit unusual. Rather than numbering from 0, we number from 1, and use 0 as the sentinel "unvisited" state. Other implementations often use '-1' for this, but I find it easier to deal with 0 and it shouldn't make any real difference provided someone doesn't write silly bugs like forgetting to actually initialize the DFS numbering. Oops. ;] llvm-svn: 206954
2014-04-23 16:08:49 +08:00
report_fatal_error(OS.str().c_str());
return M;
}
Silence gcc's -Wcomment gcc's (4.7, I think) -Wcomment warning is not "as smart" as clang's and warns even if the line right after the backslash-newline sequence only has a line comment that starts at the beginning of the line. llvm-svn: 220360
2014-10-22 10:16:06 +08:00
/*
IR forming a call graph with a diamond of triangle-shaped SCCs:
d1
/ \
d3--d2
/ \
b1 c1
/ \ / \
b3--b2 c3--c2
\ /
a1
/ \
a3--a2
All call edges go up between SCCs, and clockwise around the SCC.
*/
[LCG] Add a unittest for the LazyCallGraph. I had a weak moment and resisted this for too long. Just with the basic testing here I was able to exercise the analysis in more detail and sift out both type signature bugs in the API and a bug in the DFS numbering. All of these are fixed here as well. The unittests will be much more important for the mutation support where it is necessary to craft minimal mutations and then inspect the state of the graph. There is just no way to do that with a standard FileCheck test. However, unittesting these kinds of analyses is really quite easy, especially as they're designed with the new pass manager where there is essentially no infrastructure required to rig up the core logic and exercise it at an API level. As a minor aside about the DFS numbering bug, the DFS numbering used in LCG is a bit unusual. Rather than numbering from 0, we number from 1, and use 0 as the sentinel "unvisited" state. Other implementations often use '-1' for this, but I find it easier to deal with 0 and it shouldn't make any real difference provided someone doesn't write silly bugs like forgetting to actually initialize the DFS numbering. Oops. ;] llvm-svn: 206954
2014-04-23 16:08:49 +08:00
static const char DiamondOfTriangles[] =
"define void @a1() {\n"
"entry:\n"
" call void @a2()\n"
" call void @b2()\n"
" call void @c3()\n"
" ret void\n"
"}\n"
"define void @a2() {\n"
"entry:\n"
" call void @a3()\n"
" ret void\n"
"}\n"
"define void @a3() {\n"
"entry:\n"
" call void @a1()\n"
" ret void\n"
"}\n"
"define void @b1() {\n"
"entry:\n"
" call void @b2()\n"
" call void @d3()\n"
" ret void\n"
"}\n"
"define void @b2() {\n"
"entry:\n"
" call void @b3()\n"
" ret void\n"
"}\n"
"define void @b3() {\n"
"entry:\n"
" call void @b1()\n"
" ret void\n"
"}\n"
"define void @c1() {\n"
"entry:\n"
" call void @c2()\n"
" call void @d2()\n"
" ret void\n"
"}\n"
"define void @c2() {\n"
"entry:\n"
" call void @c3()\n"
" ret void\n"
"}\n"
"define void @c3() {\n"
"entry:\n"
" call void @c1()\n"
" ret void\n"
"}\n"
"define void @d1() {\n"
"entry:\n"
" call void @d2()\n"
" ret void\n"
"}\n"
"define void @d2() {\n"
"entry:\n"
" call void @d3()\n"
" ret void\n"
"}\n"
"define void @d3() {\n"
"entry:\n"
" call void @d1()\n"
" ret void\n"
"}\n";
TEST(LazyCallGraphTest, BasicGraphFormation) {
std::unique_ptr<Module> M = parseAssembly(DiamondOfTriangles);
LazyCallGraph CG(*M);
// The order of the entry nodes should be stable w.r.t. the source order of
// the IR, and everything in our module is an entry node, so just directly
// build variables for each node.
auto I = CG.begin();
[LCG] Switch the primary node iterator to be a *much* more normal C++ iterator, returning a Node by reference on dereference. llvm-svn: 207048
2014-04-24 07:34:48 +08:00
LazyCallGraph::Node &A1 = *I++;
EXPECT_EQ("a1", A1.getFunction().getName());
LazyCallGraph::Node &A2 = *I++;
EXPECT_EQ("a2", A2.getFunction().getName());
LazyCallGraph::Node &A3 = *I++;
EXPECT_EQ("a3", A3.getFunction().getName());
LazyCallGraph::Node &B1 = *I++;
EXPECT_EQ("b1", B1.getFunction().getName());
LazyCallGraph::Node &B2 = *I++;
EXPECT_EQ("b2", B2.getFunction().getName());
LazyCallGraph::Node &B3 = *I++;
EXPECT_EQ("b3", B3.getFunction().getName());
LazyCallGraph::Node &C1 = *I++;
EXPECT_EQ("c1", C1.getFunction().getName());
LazyCallGraph::Node &C2 = *I++;
EXPECT_EQ("c2", C2.getFunction().getName());
LazyCallGraph::Node &C3 = *I++;
EXPECT_EQ("c3", C3.getFunction().getName());
LazyCallGraph::Node &D1 = *I++;
EXPECT_EQ("d1", D1.getFunction().getName());
LazyCallGraph::Node &D2 = *I++;
EXPECT_EQ("d2", D2.getFunction().getName());
LazyCallGraph::Node &D3 = *I++;
EXPECT_EQ("d3", D3.getFunction().getName());
[LCG] Add a unittest for the LazyCallGraph. I had a weak moment and resisted this for too long. Just with the basic testing here I was able to exercise the analysis in more detail and sift out both type signature bugs in the API and a bug in the DFS numbering. All of these are fixed here as well. The unittests will be much more important for the mutation support where it is necessary to craft minimal mutations and then inspect the state of the graph. There is just no way to do that with a standard FileCheck test. However, unittesting these kinds of analyses is really quite easy, especially as they're designed with the new pass manager where there is essentially no infrastructure required to rig up the core logic and exercise it at an API level. As a minor aside about the DFS numbering bug, the DFS numbering used in LCG is a bit unusual. Rather than numbering from 0, we number from 1, and use 0 as the sentinel "unvisited" state. Other implementations often use '-1' for this, but I find it easier to deal with 0 and it shouldn't make any real difference provided someone doesn't write silly bugs like forgetting to actually initialize the DFS numbering. Oops. ;] llvm-svn: 206954
2014-04-23 16:08:49 +08:00
EXPECT_EQ(CG.end(), I);
// Build vectors and sort them for the rest of the assertions to make them
// independent of order.
std::vector<std::string> Nodes;
[LCG] Switch the primary node iterator to be a *much* more normal C++ iterator, returning a Node by reference on dereference. llvm-svn: 207048
2014-04-24 07:34:48 +08:00
for (LazyCallGraph::Node &N : A1)
Nodes.push_back(N.getFunction().getName());
[LCG] Add a unittest for the LazyCallGraph. I had a weak moment and resisted this for too long. Just with the basic testing here I was able to exercise the analysis in more detail and sift out both type signature bugs in the API and a bug in the DFS numbering. All of these are fixed here as well. The unittests will be much more important for the mutation support where it is necessary to craft minimal mutations and then inspect the state of the graph. There is just no way to do that with a standard FileCheck test. However, unittesting these kinds of analyses is really quite easy, especially as they're designed with the new pass manager where there is essentially no infrastructure required to rig up the core logic and exercise it at an API level. As a minor aside about the DFS numbering bug, the DFS numbering used in LCG is a bit unusual. Rather than numbering from 0, we number from 1, and use 0 as the sentinel "unvisited" state. Other implementations often use '-1' for this, but I find it easier to deal with 0 and it shouldn't make any real difference provided someone doesn't write silly bugs like forgetting to actually initialize the DFS numbering. Oops. ;] llvm-svn: 206954
2014-04-23 16:08:49 +08:00
std::sort(Nodes.begin(), Nodes.end());
EXPECT_EQ("a2", Nodes[0]);
EXPECT_EQ("b2", Nodes[1]);
EXPECT_EQ("c3", Nodes[2]);
Nodes.clear();
[LCG] Switch the primary node iterator to be a *much* more normal C++ iterator, returning a Node by reference on dereference. llvm-svn: 207048
2014-04-24 07:34:48 +08:00
EXPECT_EQ(A2.end(), std::next(A2.begin()));
EXPECT_EQ("a3", A2.begin()->getFunction().getName());
EXPECT_EQ(A3.end(), std::next(A3.begin()));
EXPECT_EQ("a1", A3.begin()->getFunction().getName());
[LCG] Add a unittest for the LazyCallGraph. I had a weak moment and resisted this for too long. Just with the basic testing here I was able to exercise the analysis in more detail and sift out both type signature bugs in the API and a bug in the DFS numbering. All of these are fixed here as well. The unittests will be much more important for the mutation support where it is necessary to craft minimal mutations and then inspect the state of the graph. There is just no way to do that with a standard FileCheck test. However, unittesting these kinds of analyses is really quite easy, especially as they're designed with the new pass manager where there is essentially no infrastructure required to rig up the core logic and exercise it at an API level. As a minor aside about the DFS numbering bug, the DFS numbering used in LCG is a bit unusual. Rather than numbering from 0, we number from 1, and use 0 as the sentinel "unvisited" state. Other implementations often use '-1' for this, but I find it easier to deal with 0 and it shouldn't make any real difference provided someone doesn't write silly bugs like forgetting to actually initialize the DFS numbering. Oops. ;] llvm-svn: 206954
2014-04-23 16:08:49 +08:00
[LCG] Switch the primary node iterator to be a *much* more normal C++ iterator, returning a Node by reference on dereference. llvm-svn: 207048
2014-04-24 07:34:48 +08:00
for (LazyCallGraph::Node &N : B1)
Nodes.push_back(N.getFunction().getName());
[LCG] Add a unittest for the LazyCallGraph. I had a weak moment and resisted this for too long. Just with the basic testing here I was able to exercise the analysis in more detail and sift out both type signature bugs in the API and a bug in the DFS numbering. All of these are fixed here as well. The unittests will be much more important for the mutation support where it is necessary to craft minimal mutations and then inspect the state of the graph. There is just no way to do that with a standard FileCheck test. However, unittesting these kinds of analyses is really quite easy, especially as they're designed with the new pass manager where there is essentially no infrastructure required to rig up the core logic and exercise it at an API level. As a minor aside about the DFS numbering bug, the DFS numbering used in LCG is a bit unusual. Rather than numbering from 0, we number from 1, and use 0 as the sentinel "unvisited" state. Other implementations often use '-1' for this, but I find it easier to deal with 0 and it shouldn't make any real difference provided someone doesn't write silly bugs like forgetting to actually initialize the DFS numbering. Oops. ;] llvm-svn: 206954
2014-04-23 16:08:49 +08:00
std::sort(Nodes.begin(), Nodes.end());
EXPECT_EQ("b2", Nodes[0]);
EXPECT_EQ("d3", Nodes[1]);
Nodes.clear();
[LCG] Switch the primary node iterator to be a *much* more normal C++ iterator, returning a Node by reference on dereference. llvm-svn: 207048
2014-04-24 07:34:48 +08:00
EXPECT_EQ(B2.end(), std::next(B2.begin()));
EXPECT_EQ("b3", B2.begin()->getFunction().getName());
EXPECT_EQ(B3.end(), std::next(B3.begin()));
EXPECT_EQ("b1", B3.begin()->getFunction().getName());
[LCG] Add a unittest for the LazyCallGraph. I had a weak moment and resisted this for too long. Just with the basic testing here I was able to exercise the analysis in more detail and sift out both type signature bugs in the API and a bug in the DFS numbering. All of these are fixed here as well. The unittests will be much more important for the mutation support where it is necessary to craft minimal mutations and then inspect the state of the graph. There is just no way to do that with a standard FileCheck test. However, unittesting these kinds of analyses is really quite easy, especially as they're designed with the new pass manager where there is essentially no infrastructure required to rig up the core logic and exercise it at an API level. As a minor aside about the DFS numbering bug, the DFS numbering used in LCG is a bit unusual. Rather than numbering from 0, we number from 1, and use 0 as the sentinel "unvisited" state. Other implementations often use '-1' for this, but I find it easier to deal with 0 and it shouldn't make any real difference provided someone doesn't write silly bugs like forgetting to actually initialize the DFS numbering. Oops. ;] llvm-svn: 206954
2014-04-23 16:08:49 +08:00
[LCG] Switch the primary node iterator to be a *much* more normal C++ iterator, returning a Node by reference on dereference. llvm-svn: 207048
2014-04-24 07:34:48 +08:00
for (LazyCallGraph::Node &N : C1)
Nodes.push_back(N.getFunction().getName());
[LCG] Add a unittest for the LazyCallGraph. I had a weak moment and resisted this for too long. Just with the basic testing here I was able to exercise the analysis in more detail and sift out both type signature bugs in the API and a bug in the DFS numbering. All of these are fixed here as well. The unittests will be much more important for the mutation support where it is necessary to craft minimal mutations and then inspect the state of the graph. There is just no way to do that with a standard FileCheck test. However, unittesting these kinds of analyses is really quite easy, especially as they're designed with the new pass manager where there is essentially no infrastructure required to rig up the core logic and exercise it at an API level. As a minor aside about the DFS numbering bug, the DFS numbering used in LCG is a bit unusual. Rather than numbering from 0, we number from 1, and use 0 as the sentinel "unvisited" state. Other implementations often use '-1' for this, but I find it easier to deal with 0 and it shouldn't make any real difference provided someone doesn't write silly bugs like forgetting to actually initialize the DFS numbering. Oops. ;] llvm-svn: 206954
2014-04-23 16:08:49 +08:00
std::sort(Nodes.begin(), Nodes.end());
EXPECT_EQ("c2", Nodes[0]);
EXPECT_EQ("d2", Nodes[1]);
Nodes.clear();
[LCG] Switch the primary node iterator to be a *much* more normal C++ iterator, returning a Node by reference on dereference. llvm-svn: 207048
2014-04-24 07:34:48 +08:00
EXPECT_EQ(C2.end(), std::next(C2.begin()));
EXPECT_EQ("c3", C2.begin()->getFunction().getName());
EXPECT_EQ(C3.end(), std::next(C3.begin()));
EXPECT_EQ("c1", C3.begin()->getFunction().getName());
EXPECT_EQ(D1.end(), std::next(D1.begin()));
EXPECT_EQ("d2", D1.begin()->getFunction().getName());
EXPECT_EQ(D2.end(), std::next(D2.begin()));
EXPECT_EQ("d3", D2.begin()->getFunction().getName());
EXPECT_EQ(D3.end(), std::next(D3.begin()));
EXPECT_EQ("d1", D3.begin()->getFunction().getName());
[LCG] Add a unittest for the LazyCallGraph. I had a weak moment and resisted this for too long. Just with the basic testing here I was able to exercise the analysis in more detail and sift out both type signature bugs in the API and a bug in the DFS numbering. All of these are fixed here as well. The unittests will be much more important for the mutation support where it is necessary to craft minimal mutations and then inspect the state of the graph. There is just no way to do that with a standard FileCheck test. However, unittesting these kinds of analyses is really quite easy, especially as they're designed with the new pass manager where there is essentially no infrastructure required to rig up the core logic and exercise it at an API level. As a minor aside about the DFS numbering bug, the DFS numbering used in LCG is a bit unusual. Rather than numbering from 0, we number from 1, and use 0 as the sentinel "unvisited" state. Other implementations often use '-1' for this, but I find it easier to deal with 0 and it shouldn't make any real difference provided someone doesn't write silly bugs like forgetting to actually initialize the DFS numbering. Oops. ;] llvm-svn: 206954
2014-04-23 16:08:49 +08:00
// Now lets look at the SCCs.
auto SCCI = CG.postorder_scc_begin();
[LCG] Normalize the post-order SCC iterator to just iterate over the SCC values rather than having pointers in weird places. llvm-svn: 207053
2014-04-24 07:51:07 +08:00
LazyCallGraph::SCC &D = *SCCI++;
for (LazyCallGraph::Node *N : D)
[LCG] Add a unittest for the LazyCallGraph. I had a weak moment and resisted this for too long. Just with the basic testing here I was able to exercise the analysis in more detail and sift out both type signature bugs in the API and a bug in the DFS numbering. All of these are fixed here as well. The unittests will be much more important for the mutation support where it is necessary to craft minimal mutations and then inspect the state of the graph. There is just no way to do that with a standard FileCheck test. However, unittesting these kinds of analyses is really quite easy, especially as they're designed with the new pass manager where there is essentially no infrastructure required to rig up the core logic and exercise it at an API level. As a minor aside about the DFS numbering bug, the DFS numbering used in LCG is a bit unusual. Rather than numbering from 0, we number from 1, and use 0 as the sentinel "unvisited" state. Other implementations often use '-1' for this, but I find it easier to deal with 0 and it shouldn't make any real difference provided someone doesn't write silly bugs like forgetting to actually initialize the DFS numbering. Oops. ;] llvm-svn: 206954
2014-04-23 16:08:49 +08:00
Nodes.push_back(N->getFunction().getName());
std::sort(Nodes.begin(), Nodes.end());
[LCG] Re-order expectations to provide more useful output when debugging an issue. This way you see that the number of nodes was wrong before a crash due to accessing too many nodes. llvm-svn: 207094
2014-04-24 17:59:56 +08:00
EXPECT_EQ(3u, Nodes.size());
[LCG] Add a unittest for the LazyCallGraph. I had a weak moment and resisted this for too long. Just with the basic testing here I was able to exercise the analysis in more detail and sift out both type signature bugs in the API and a bug in the DFS numbering. All of these are fixed here as well. The unittests will be much more important for the mutation support where it is necessary to craft minimal mutations and then inspect the state of the graph. There is just no way to do that with a standard FileCheck test. However, unittesting these kinds of analyses is really quite easy, especially as they're designed with the new pass manager where there is essentially no infrastructure required to rig up the core logic and exercise it at an API level. As a minor aside about the DFS numbering bug, the DFS numbering used in LCG is a bit unusual. Rather than numbering from 0, we number from 1, and use 0 as the sentinel "unvisited" state. Other implementations often use '-1' for this, but I find it easier to deal with 0 and it shouldn't make any real difference provided someone doesn't write silly bugs like forgetting to actually initialize the DFS numbering. Oops. ;] llvm-svn: 206954
2014-04-23 16:08:49 +08:00
EXPECT_EQ("d1", Nodes[0]);
EXPECT_EQ("d2", Nodes[1]);
EXPECT_EQ("d3", Nodes[2]);
Nodes.clear();
[LCG] Add some basic methods for querying the parent/child relationships of SCCs in the SCC DAG. Exercise them in the big graph test case. These will be especially useful for establishing invariants in insertion logic. llvm-svn: 207749
2014-05-01 20:12:42 +08:00
EXPECT_FALSE(D.isParentOf(D));
EXPECT_FALSE(D.isChildOf(D));
EXPECT_FALSE(D.isAncestorOf(D));
EXPECT_FALSE(D.isDescendantOf(D));
[LCG] Add a unittest for the LazyCallGraph. I had a weak moment and resisted this for too long. Just with the basic testing here I was able to exercise the analysis in more detail and sift out both type signature bugs in the API and a bug in the DFS numbering. All of these are fixed here as well. The unittests will be much more important for the mutation support where it is necessary to craft minimal mutations and then inspect the state of the graph. There is just no way to do that with a standard FileCheck test. However, unittesting these kinds of analyses is really quite easy, especially as they're designed with the new pass manager where there is essentially no infrastructure required to rig up the core logic and exercise it at an API level. As a minor aside about the DFS numbering bug, the DFS numbering used in LCG is a bit unusual. Rather than numbering from 0, we number from 1, and use 0 as the sentinel "unvisited" state. Other implementations often use '-1' for this, but I find it easier to deal with 0 and it shouldn't make any real difference provided someone doesn't write silly bugs like forgetting to actually initialize the DFS numbering. Oops. ;] llvm-svn: 206954
2014-04-23 16:08:49 +08:00
[LCG] Normalize the post-order SCC iterator to just iterate over the SCC values rather than having pointers in weird places. llvm-svn: 207053
2014-04-24 07:51:07 +08:00
LazyCallGraph::SCC &C = *SCCI++;
for (LazyCallGraph::Node *N : C)
[LCG] Add a unittest for the LazyCallGraph. I had a weak moment and resisted this for too long. Just with the basic testing here I was able to exercise the analysis in more detail and sift out both type signature bugs in the API and a bug in the DFS numbering. All of these are fixed here as well. The unittests will be much more important for the mutation support where it is necessary to craft minimal mutations and then inspect the state of the graph. There is just no way to do that with a standard FileCheck test. However, unittesting these kinds of analyses is really quite easy, especially as they're designed with the new pass manager where there is essentially no infrastructure required to rig up the core logic and exercise it at an API level. As a minor aside about the DFS numbering bug, the DFS numbering used in LCG is a bit unusual. Rather than numbering from 0, we number from 1, and use 0 as the sentinel "unvisited" state. Other implementations often use '-1' for this, but I find it easier to deal with 0 and it shouldn't make any real difference provided someone doesn't write silly bugs like forgetting to actually initialize the DFS numbering. Oops. ;] llvm-svn: 206954
2014-04-23 16:08:49 +08:00
Nodes.push_back(N->getFunction().getName());
std::sort(Nodes.begin(), Nodes.end());
[LCG] Re-order expectations to provide more useful output when debugging an issue. This way you see that the number of nodes was wrong before a crash due to accessing too many nodes. llvm-svn: 207094
2014-04-24 17:59:56 +08:00
EXPECT_EQ(3u, Nodes.size());
[LCG] Add a unittest for the LazyCallGraph. I had a weak moment and resisted this for too long. Just with the basic testing here I was able to exercise the analysis in more detail and sift out both type signature bugs in the API and a bug in the DFS numbering. All of these are fixed here as well. The unittests will be much more important for the mutation support where it is necessary to craft minimal mutations and then inspect the state of the graph. There is just no way to do that with a standard FileCheck test. However, unittesting these kinds of analyses is really quite easy, especially as they're designed with the new pass manager where there is essentially no infrastructure required to rig up the core logic and exercise it at an API level. As a minor aside about the DFS numbering bug, the DFS numbering used in LCG is a bit unusual. Rather than numbering from 0, we number from 1, and use 0 as the sentinel "unvisited" state. Other implementations often use '-1' for this, but I find it easier to deal with 0 and it shouldn't make any real difference provided someone doesn't write silly bugs like forgetting to actually initialize the DFS numbering. Oops. ;] llvm-svn: 206954
2014-04-23 16:08:49 +08:00
EXPECT_EQ("c1", Nodes[0]);
EXPECT_EQ("c2", Nodes[1]);
EXPECT_EQ("c3", Nodes[2]);
Nodes.clear();
[LCG] Add some basic methods for querying the parent/child relationships of SCCs in the SCC DAG. Exercise them in the big graph test case. These will be especially useful for establishing invariants in insertion logic. llvm-svn: 207749
2014-05-01 20:12:42 +08:00
EXPECT_TRUE(C.isParentOf(D));
EXPECT_FALSE(C.isChildOf(D));
EXPECT_TRUE(C.isAncestorOf(D));
EXPECT_FALSE(C.isDescendantOf(D));
[LCG] Add a unittest for the LazyCallGraph. I had a weak moment and resisted this for too long. Just with the basic testing here I was able to exercise the analysis in more detail and sift out both type signature bugs in the API and a bug in the DFS numbering. All of these are fixed here as well. The unittests will be much more important for the mutation support where it is necessary to craft minimal mutations and then inspect the state of the graph. There is just no way to do that with a standard FileCheck test. However, unittesting these kinds of analyses is really quite easy, especially as they're designed with the new pass manager where there is essentially no infrastructure required to rig up the core logic and exercise it at an API level. As a minor aside about the DFS numbering bug, the DFS numbering used in LCG is a bit unusual. Rather than numbering from 0, we number from 1, and use 0 as the sentinel "unvisited" state. Other implementations often use '-1' for this, but I find it easier to deal with 0 and it shouldn't make any real difference provided someone doesn't write silly bugs like forgetting to actually initialize the DFS numbering. Oops. ;] llvm-svn: 206954
2014-04-23 16:08:49 +08:00
[LCG] Normalize the post-order SCC iterator to just iterate over the SCC values rather than having pointers in weird places. llvm-svn: 207053
2014-04-24 07:51:07 +08:00
LazyCallGraph::SCC &B = *SCCI++;
for (LazyCallGraph::Node *N : B)
[LCG] Add a unittest for the LazyCallGraph. I had a weak moment and resisted this for too long. Just with the basic testing here I was able to exercise the analysis in more detail and sift out both type signature bugs in the API and a bug in the DFS numbering. All of these are fixed here as well. The unittests will be much more important for the mutation support where it is necessary to craft minimal mutations and then inspect the state of the graph. There is just no way to do that with a standard FileCheck test. However, unittesting these kinds of analyses is really quite easy, especially as they're designed with the new pass manager where there is essentially no infrastructure required to rig up the core logic and exercise it at an API level. As a minor aside about the DFS numbering bug, the DFS numbering used in LCG is a bit unusual. Rather than numbering from 0, we number from 1, and use 0 as the sentinel "unvisited" state. Other implementations often use '-1' for this, but I find it easier to deal with 0 and it shouldn't make any real difference provided someone doesn't write silly bugs like forgetting to actually initialize the DFS numbering. Oops. ;] llvm-svn: 206954
2014-04-23 16:08:49 +08:00
Nodes.push_back(N->getFunction().getName());
std::sort(Nodes.begin(), Nodes.end());
[LCG] Re-order expectations to provide more useful output when debugging an issue. This way you see that the number of nodes was wrong before a crash due to accessing too many nodes. llvm-svn: 207094
2014-04-24 17:59:56 +08:00
EXPECT_EQ(3u, Nodes.size());
[LCG] Add a unittest for the LazyCallGraph. I had a weak moment and resisted this for too long. Just with the basic testing here I was able to exercise the analysis in more detail and sift out both type signature bugs in the API and a bug in the DFS numbering. All of these are fixed here as well. The unittests will be much more important for the mutation support where it is necessary to craft minimal mutations and then inspect the state of the graph. There is just no way to do that with a standard FileCheck test. However, unittesting these kinds of analyses is really quite easy, especially as they're designed with the new pass manager where there is essentially no infrastructure required to rig up the core logic and exercise it at an API level. As a minor aside about the DFS numbering bug, the DFS numbering used in LCG is a bit unusual. Rather than numbering from 0, we number from 1, and use 0 as the sentinel "unvisited" state. Other implementations often use '-1' for this, but I find it easier to deal with 0 and it shouldn't make any real difference provided someone doesn't write silly bugs like forgetting to actually initialize the DFS numbering. Oops. ;] llvm-svn: 206954
2014-04-23 16:08:49 +08:00
EXPECT_EQ("b1", Nodes[0]);
EXPECT_EQ("b2", Nodes[1]);
EXPECT_EQ("b3", Nodes[2]);
Nodes.clear();
[LCG] Add some basic methods for querying the parent/child relationships of SCCs in the SCC DAG. Exercise them in the big graph test case. These will be especially useful for establishing invariants in insertion logic. llvm-svn: 207749
2014-05-01 20:12:42 +08:00
EXPECT_TRUE(B.isParentOf(D));
EXPECT_FALSE(B.isChildOf(D));
EXPECT_TRUE(B.isAncestorOf(D));
EXPECT_FALSE(B.isDescendantOf(D));
EXPECT_FALSE(B.isAncestorOf(C));
EXPECT_FALSE(C.isAncestorOf(B));
[LCG] Add a unittest for the LazyCallGraph. I had a weak moment and resisted this for too long. Just with the basic testing here I was able to exercise the analysis in more detail and sift out both type signature bugs in the API and a bug in the DFS numbering. All of these are fixed here as well. The unittests will be much more important for the mutation support where it is necessary to craft minimal mutations and then inspect the state of the graph. There is just no way to do that with a standard FileCheck test. However, unittesting these kinds of analyses is really quite easy, especially as they're designed with the new pass manager where there is essentially no infrastructure required to rig up the core logic and exercise it at an API level. As a minor aside about the DFS numbering bug, the DFS numbering used in LCG is a bit unusual. Rather than numbering from 0, we number from 1, and use 0 as the sentinel "unvisited" state. Other implementations often use '-1' for this, but I find it easier to deal with 0 and it shouldn't make any real difference provided someone doesn't write silly bugs like forgetting to actually initialize the DFS numbering. Oops. ;] llvm-svn: 206954
2014-04-23 16:08:49 +08:00
[LCG] Normalize the post-order SCC iterator to just iterate over the SCC values rather than having pointers in weird places. llvm-svn: 207053
2014-04-24 07:51:07 +08:00
LazyCallGraph::SCC &A = *SCCI++;
for (LazyCallGraph::Node *N : A)
[LCG] Add a unittest for the LazyCallGraph. I had a weak moment and resisted this for too long. Just with the basic testing here I was able to exercise the analysis in more detail and sift out both type signature bugs in the API and a bug in the DFS numbering. All of these are fixed here as well. The unittests will be much more important for the mutation support where it is necessary to craft minimal mutations and then inspect the state of the graph. There is just no way to do that with a standard FileCheck test. However, unittesting these kinds of analyses is really quite easy, especially as they're designed with the new pass manager where there is essentially no infrastructure required to rig up the core logic and exercise it at an API level. As a minor aside about the DFS numbering bug, the DFS numbering used in LCG is a bit unusual. Rather than numbering from 0, we number from 1, and use 0 as the sentinel "unvisited" state. Other implementations often use '-1' for this, but I find it easier to deal with 0 and it shouldn't make any real difference provided someone doesn't write silly bugs like forgetting to actually initialize the DFS numbering. Oops. ;] llvm-svn: 206954
2014-04-23 16:08:49 +08:00
Nodes.push_back(N->getFunction().getName());
std::sort(Nodes.begin(), Nodes.end());
[LCG] Re-order expectations to provide more useful output when debugging an issue. This way you see that the number of nodes was wrong before a crash due to accessing too many nodes. llvm-svn: 207094
2014-04-24 17:59:56 +08:00
EXPECT_EQ(3u, Nodes.size());
[LCG] Add a unittest for the LazyCallGraph. I had a weak moment and resisted this for too long. Just with the basic testing here I was able to exercise the analysis in more detail and sift out both type signature bugs in the API and a bug in the DFS numbering. All of these are fixed here as well. The unittests will be much more important for the mutation support where it is necessary to craft minimal mutations and then inspect the state of the graph. There is just no way to do that with a standard FileCheck test. However, unittesting these kinds of analyses is really quite easy, especially as they're designed with the new pass manager where there is essentially no infrastructure required to rig up the core logic and exercise it at an API level. As a minor aside about the DFS numbering bug, the DFS numbering used in LCG is a bit unusual. Rather than numbering from 0, we number from 1, and use 0 as the sentinel "unvisited" state. Other implementations often use '-1' for this, but I find it easier to deal with 0 and it shouldn't make any real difference provided someone doesn't write silly bugs like forgetting to actually initialize the DFS numbering. Oops. ;] llvm-svn: 206954
2014-04-23 16:08:49 +08:00
EXPECT_EQ("a1", Nodes[0]);
EXPECT_EQ("a2", Nodes[1]);
EXPECT_EQ("a3", Nodes[2]);
Nodes.clear();
[LCG] Add some basic methods for querying the parent/child relationships of SCCs in the SCC DAG. Exercise them in the big graph test case. These will be especially useful for establishing invariants in insertion logic. llvm-svn: 207749
2014-05-01 20:12:42 +08:00
EXPECT_TRUE(A.isParentOf(B));
EXPECT_TRUE(A.isParentOf(C));
EXPECT_FALSE(A.isParentOf(D));
EXPECT_TRUE(A.isAncestorOf(B));
EXPECT_TRUE(A.isAncestorOf(C));
EXPECT_TRUE(A.isAncestorOf(D));
[LCG] Add a unittest for the LazyCallGraph. I had a weak moment and resisted this for too long. Just with the basic testing here I was able to exercise the analysis in more detail and sift out both type signature bugs in the API and a bug in the DFS numbering. All of these are fixed here as well. The unittests will be much more important for the mutation support where it is necessary to craft minimal mutations and then inspect the state of the graph. There is just no way to do that with a standard FileCheck test. However, unittesting these kinds of analyses is really quite easy, especially as they're designed with the new pass manager where there is essentially no infrastructure required to rig up the core logic and exercise it at an API level. As a minor aside about the DFS numbering bug, the DFS numbering used in LCG is a bit unusual. Rather than numbering from 0, we number from 1, and use 0 as the sentinel "unvisited" state. Other implementations often use '-1' for this, but I find it easier to deal with 0 and it shouldn't make any real difference provided someone doesn't write silly bugs like forgetting to actually initialize the DFS numbering. Oops. ;] llvm-svn: 206954
2014-04-23 16:08:49 +08:00
EXPECT_EQ(CG.postorder_scc_end(), SCCI);
}
[LCG] Implement Tarjan's algorithm correctly this time. We have to walk up the stack finishing the exploration of each entries children before we're finished in addition to accounting for their low-links. Added a unittest that really hammers home the need for this with interlocking cycles that would each appear distinct otherwise and crash or compute the wrong result. As part of this, nuke a stale fixme and bring the rest of the implementation still more closely in line with the original algorithm. llvm-svn: 206966
2014-04-23 18:31:17 +08:00
static Function &lookupFunction(Module &M, StringRef Name) {
for (Function &F : M)
if (F.getName() == Name)
return F;
report_fatal_error("Couldn't find function!");
}
[LCG] Add the most basic of edge insertion to the lazy call graph. This just handles the pre-DFS case. Also add some test cases for this case to make sure it works. llvm-svn: 207411
2014-04-28 19:10:23 +08:00
TEST(LazyCallGraphTest, BasicGraphMutation) {
std::unique_ptr<Module> M = parseAssembly(
"define void @a() {\n"
"entry:\n"
" call void @b()\n"
" call void @c()\n"
" ret void\n"
"}\n"
"define void @b() {\n"
"entry:\n"
" ret void\n"
"}\n"
"define void @c() {\n"
"entry:\n"
" ret void\n"
"}\n");
LazyCallGraph CG(*M);
LazyCallGraph::Node &A = CG.get(lookupFunction(*M, "a"));
LazyCallGraph::Node &B = CG.get(lookupFunction(*M, "b"));
EXPECT_EQ(2, std::distance(A.begin(), A.end()));
EXPECT_EQ(0, std::distance(B.begin(), B.end()));
CG.insertEdge(B, lookupFunction(*M, "c"));
EXPECT_EQ(1, std::distance(B.begin(), B.end()));
LazyCallGraph::Node &C = *B.begin();
EXPECT_EQ(0, std::distance(C.begin(), C.end()));
CG.insertEdge(C, B.getFunction());
EXPECT_EQ(1, std::distance(C.begin(), C.end()));
EXPECT_EQ(&B, &*C.begin());
CG.insertEdge(C, C.getFunction());
EXPECT_EQ(2, std::distance(C.begin(), C.end()));
EXPECT_EQ(&B, &*C.begin());
[LCG] Actually test the *basic* edge removal bits (IE, the non-SCC bits), and discover that it's totally broken. Yay tests. Boo bug. Fix the basic edge removal so that it works by nulling out the removed edges rather than actually removing them. This leaves the indices valid in the map from callee to index, and preserves some of the locality for iterating over edges. The iterator is made bidirectional to reflect that it now has to skip over null entries, and the skipping logic is layered onto it. As future work, I would like to track essentially the "load factor" of the edge list, and when it falls below a threshold do a compaction. An alternative I considered (and continue to consider) is storing the callees in a doubly linked list where each element of the list is in a set (which is essentially the classical linked-hash-table datastructure). The problem with that approach is that either you need to heap allocate the linked list nodes and use pointers to them, or use a bucket hash table (with even *more* linked list pointer overhead!), etc. It's pretty easy to get 5x overhead for values that are just pointers. So far, I think punching holes in the vector, and periodic compaction is likely to be much more efficient overall in the space/time tradeoff. llvm-svn: 207619
2014-04-30 15:45:27 +08:00
EXPECT_EQ(&C, &*std::next(C.begin()));
CG.removeEdge(C, B.getFunction());
EXPECT_EQ(1, std::distance(C.begin(), C.end()));
EXPECT_EQ(&C, &*C.begin());
CG.removeEdge(C, C.getFunction());
EXPECT_EQ(0, std::distance(C.begin(), C.end()));
CG.removeEdge(B, C.getFunction());
EXPECT_EQ(0, std::distance(B.begin(), B.end()));
[LCG] Add the most basic of edge insertion to the lazy call graph. This just handles the pre-DFS case. Also add some test cases for this case to make sure it works. llvm-svn: 207411
2014-04-28 19:10:23 +08:00
}
[LCG] Implement Tarjan's algorithm correctly this time. We have to walk up the stack finishing the exploration of each entries children before we're finished in addition to accounting for their low-links. Added a unittest that really hammers home the need for this with interlocking cycles that would each appear distinct otherwise and crash or compute the wrong result. As part of this, nuke a stale fixme and bring the rest of the implementation still more closely in line with the original algorithm. llvm-svn: 206966
2014-04-23 18:31:17 +08:00
TEST(LazyCallGraphTest, MultiArmSCC) {
// Two interlocking cycles. The really useful thing about this SCC is that it
// will require Tarjan's DFS to backtrack and finish processing all of the
// children of each node in the SCC.
std::unique_ptr<Module> M = parseAssembly(
"define void @a() {\n"
"entry:\n"
" call void @b()\n"
" call void @d()\n"
" ret void\n"
"}\n"
"define void @b() {\n"
"entry:\n"
" call void @c()\n"
" ret void\n"
"}\n"
"define void @c() {\n"
"entry:\n"
" call void @a()\n"
" ret void\n"
"}\n"
"define void @d() {\n"
"entry:\n"
" call void @e()\n"
" ret void\n"
"}\n"
"define void @e() {\n"
"entry:\n"
" call void @a()\n"
" ret void\n"
"}\n");
LazyCallGraph CG(*M);
// Force the graph to be fully expanded.
auto SCCI = CG.postorder_scc_begin();
[LCG] Normalize the post-order SCC iterator to just iterate over the SCC values rather than having pointers in weird places. llvm-svn: 207053
2014-04-24 07:51:07 +08:00
LazyCallGraph::SCC &SCC = *SCCI++;
[LCG] Implement Tarjan's algorithm correctly this time. We have to walk up the stack finishing the exploration of each entries children before we're finished in addition to accounting for their low-links. Added a unittest that really hammers home the need for this with interlocking cycles that would each appear distinct otherwise and crash or compute the wrong result. As part of this, nuke a stale fixme and bring the rest of the implementation still more closely in line with the original algorithm. llvm-svn: 206966
2014-04-23 18:31:17 +08:00
EXPECT_EQ(CG.postorder_scc_end(), SCCI);
[LCG] Switch the SCC lookup to be in terms of call graph nodes rather than functions. So far, this access pattern is *much* more common. It seems likely that any user of this interface is going to have nodes at the point that they are querying the SCCs. No functionality changed. llvm-svn: 207045
2014-04-24 07:12:06 +08:00
LazyCallGraph::Node &A = *CG.lookup(lookupFunction(*M, "a"));
LazyCallGraph::Node &B = *CG.lookup(lookupFunction(*M, "b"));
LazyCallGraph::Node &C = *CG.lookup(lookupFunction(*M, "c"));
LazyCallGraph::Node &D = *CG.lookup(lookupFunction(*M, "d"));
LazyCallGraph::Node &E = *CG.lookup(lookupFunction(*M, "e"));
[LCG] Normalize the post-order SCC iterator to just iterate over the SCC values rather than having pointers in weird places. llvm-svn: 207053
2014-04-24 07:51:07 +08:00
EXPECT_EQ(&SCC, CG.lookupSCC(A));
EXPECT_EQ(&SCC, CG.lookupSCC(B));
EXPECT_EQ(&SCC, CG.lookupSCC(C));
EXPECT_EQ(&SCC, CG.lookupSCC(D));
EXPECT_EQ(&SCC, CG.lookupSCC(E));
[LCG] Implement Tarjan's algorithm correctly this time. We have to walk up the stack finishing the exploration of each entries children before we're finished in addition to accounting for their low-links. Added a unittest that really hammers home the need for this with interlocking cycles that would each appear distinct otherwise and crash or compute the wrong result. As part of this, nuke a stale fixme and bring the rest of the implementation still more closely in line with the original algorithm. llvm-svn: 206966
2014-04-23 18:31:17 +08:00
}
[LCG] Reorder the tests to be a bit more logical: inter-SCC mutation before intra-SCC mutation, insertion before removal. No functionality changed. llvm-svn: 207934
2014-05-04 17:38:23 +08:00
TEST(LazyCallGraphTest, OutgoingSCCEdgeInsertion) {
std::unique_ptr<Module> M = parseAssembly(
"define void @a() {\n"
"entry:\n"
" call void @b()\n"
" call void @c()\n"
" ret void\n"
"}\n"
"define void @b() {\n"
"entry:\n"
" call void @d()\n"
" ret void\n"
"}\n"
"define void @c() {\n"
"entry:\n"
" call void @d()\n"
" ret void\n"
"}\n"
"define void @d() {\n"
"entry:\n"
" ret void\n"
"}\n");
LazyCallGraph CG(*M);
// Force the graph to be fully expanded.
for (LazyCallGraph::SCC &C : CG.postorder_sccs())
(void)C;
LazyCallGraph::Node &A = *CG.lookup(lookupFunction(*M, "a"));
LazyCallGraph::Node &B = *CG.lookup(lookupFunction(*M, "b"));
LazyCallGraph::Node &C = *CG.lookup(lookupFunction(*M, "c"));
LazyCallGraph::Node &D = *CG.lookup(lookupFunction(*M, "d"));
LazyCallGraph::SCC &AC = *CG.lookupSCC(A);
LazyCallGraph::SCC &BC = *CG.lookupSCC(B);
LazyCallGraph::SCC &CC = *CG.lookupSCC(C);
LazyCallGraph::SCC &DC = *CG.lookupSCC(D);
EXPECT_TRUE(AC.isAncestorOf(BC));
EXPECT_TRUE(AC.isAncestorOf(CC));
EXPECT_TRUE(AC.isAncestorOf(DC));
EXPECT_TRUE(DC.isDescendantOf(AC));
EXPECT_TRUE(DC.isDescendantOf(BC));
EXPECT_TRUE(DC.isDescendantOf(CC));
EXPECT_EQ(2, std::distance(A.begin(), A.end()));
AC.insertOutgoingEdge(A, D);
EXPECT_EQ(3, std::distance(A.begin(), A.end()));
EXPECT_TRUE(AC.isParentOf(DC));
EXPECT_EQ(&AC, CG.lookupSCC(A));
EXPECT_EQ(&BC, CG.lookupSCC(B));
EXPECT_EQ(&CC, CG.lookupSCC(C));
EXPECT_EQ(&DC, CG.lookupSCC(D));
}
[LCG] Add the last (and most complex) of the edge insertion mutation operations on the call graph. This one forms a cycle, and while not as complex as removing an internal edge from an SCC, it involves a reasonable amount of work to find all of the nodes newly connected in a cycle. Also somewhat alarming is the worst case complexity here: it might have to walk roughly the entire SCC inverse DAG to insert a single edge. This is carefully documented in the API (I hope). llvm-svn: 207935
2014-05-04 17:38:32 +08:00
TEST(LazyCallGraphTest, IncomingSCCEdgeInsertion) {
// We want to ensure we can add edges even across complex diamond graphs, so
// we use the diamond of triangles graph defined above. The ascii diagram is
// repeated here for easy reference.
//
// d1 |
// / \ |
// d3--d2 |
// / \ |
// b1 c1 |
// / \ / \ |
// b3--b2 c3--c2 |
// \ / |
// a1 |
// / \ |
// a3--a2 |
//
std::unique_ptr<Module> M = parseAssembly(DiamondOfTriangles);
LazyCallGraph CG(*M);
// Force the graph to be fully expanded.
for (LazyCallGraph::SCC &C : CG.postorder_sccs())
(void)C;
LazyCallGraph::Node &A1 = *CG.lookup(lookupFunction(*M, "a1"));
LazyCallGraph::Node &A2 = *CG.lookup(lookupFunction(*M, "a2"));
LazyCallGraph::Node &A3 = *CG.lookup(lookupFunction(*M, "a3"));
LazyCallGraph::Node &B1 = *CG.lookup(lookupFunction(*M, "b1"));
LazyCallGraph::Node &B2 = *CG.lookup(lookupFunction(*M, "b2"));
LazyCallGraph::Node &B3 = *CG.lookup(lookupFunction(*M, "b3"));
LazyCallGraph::Node &C1 = *CG.lookup(lookupFunction(*M, "c1"));
LazyCallGraph::Node &C2 = *CG.lookup(lookupFunction(*M, "c2"));
LazyCallGraph::Node &C3 = *CG.lookup(lookupFunction(*M, "c3"));
LazyCallGraph::Node &D1 = *CG.lookup(lookupFunction(*M, "d1"));
LazyCallGraph::Node &D2 = *CG.lookup(lookupFunction(*M, "d2"));
LazyCallGraph::Node &D3 = *CG.lookup(lookupFunction(*M, "d3"));
LazyCallGraph::SCC &AC = *CG.lookupSCC(A1);
LazyCallGraph::SCC &BC = *CG.lookupSCC(B1);
LazyCallGraph::SCC &CC = *CG.lookupSCC(C1);
LazyCallGraph::SCC &DC = *CG.lookupSCC(D1);
ASSERT_EQ(&AC, CG.lookupSCC(A2));
ASSERT_EQ(&AC, CG.lookupSCC(A3));
ASSERT_EQ(&BC, CG.lookupSCC(B2));
ASSERT_EQ(&BC, CG.lookupSCC(B3));
ASSERT_EQ(&CC, CG.lookupSCC(C2));
ASSERT_EQ(&CC, CG.lookupSCC(C3));
ASSERT_EQ(&DC, CG.lookupSCC(D2));
ASSERT_EQ(&DC, CG.lookupSCC(D3));
ASSERT_EQ(1, std::distance(D2.begin(), D2.end()));
// Add an edge to make the graph:
//
// d1 |
// / \ |
// d3--d2---. |
// / \ | |
// b1 c1 | |
// / \ / \ / |
// b3--b2 c3--c2 |
// \ / |
// a1 |
// / \ |
// a3--a2 |
CC.insertIncomingEdge(D2, C2);
// Make sure we connected the nodes.
EXPECT_EQ(2, std::distance(D2.begin(), D2.end()));
// Make sure we have the correct nodes in the SCC sets.
EXPECT_EQ(&AC, CG.lookupSCC(A1));
EXPECT_EQ(&AC, CG.lookupSCC(A2));
EXPECT_EQ(&AC, CG.lookupSCC(A3));
EXPECT_EQ(&BC, CG.lookupSCC(B1));
EXPECT_EQ(&BC, CG.lookupSCC(B2));
EXPECT_EQ(&BC, CG.lookupSCC(B3));
EXPECT_EQ(&CC, CG.lookupSCC(C1));
EXPECT_EQ(&CC, CG.lookupSCC(C2));
EXPECT_EQ(&CC, CG.lookupSCC(C3));
EXPECT_EQ(&CC, CG.lookupSCC(D1));
EXPECT_EQ(&CC, CG.lookupSCC(D2));
EXPECT_EQ(&CC, CG.lookupSCC(D3));
// And that ancestry tests have been updated.
EXPECT_TRUE(AC.isParentOf(BC));
EXPECT_TRUE(AC.isParentOf(CC));
EXPECT_FALSE(AC.isAncestorOf(DC));
EXPECT_FALSE(BC.isAncestorOf(DC));
EXPECT_FALSE(CC.isAncestorOf(DC));
}
TEST(LazyCallGraphTest, IncomingSCCEdgeInsertionMidTraversal) {
// This is the same fundamental test as the previous, but we perform it
// having only partially walked the SCCs of the graph.
std::unique_ptr<Module> M = parseAssembly(DiamondOfTriangles);
LazyCallGraph CG(*M);
// Walk the SCCs until we find the one containing 'c1'.
auto SCCI = CG.postorder_scc_begin(), SCCE = CG.postorder_scc_end();
ASSERT_NE(SCCI, SCCE);
LazyCallGraph::SCC &DC = *SCCI;
ASSERT_NE(&DC, nullptr);
++SCCI;
ASSERT_NE(SCCI, SCCE);
LazyCallGraph::SCC &CC = *SCCI;
ASSERT_NE(&CC, nullptr);
ASSERT_EQ(nullptr, CG.lookup(lookupFunction(*M, "a1")));
ASSERT_EQ(nullptr, CG.lookup(lookupFunction(*M, "a2")));
ASSERT_EQ(nullptr, CG.lookup(lookupFunction(*M, "a3")));
ASSERT_EQ(nullptr, CG.lookup(lookupFunction(*M, "b1")));
ASSERT_EQ(nullptr, CG.lookup(lookupFunction(*M, "b2")));
ASSERT_EQ(nullptr, CG.lookup(lookupFunction(*M, "b3")));
LazyCallGraph::Node &C1 = *CG.lookup(lookupFunction(*M, "c1"));
LazyCallGraph::Node &C2 = *CG.lookup(lookupFunction(*M, "c2"));
LazyCallGraph::Node &C3 = *CG.lookup(lookupFunction(*M, "c3"));
LazyCallGraph::Node &D1 = *CG.lookup(lookupFunction(*M, "d1"));
LazyCallGraph::Node &D2 = *CG.lookup(lookupFunction(*M, "d2"));
LazyCallGraph::Node &D3 = *CG.lookup(lookupFunction(*M, "d3"));
ASSERT_EQ(&CC, CG.lookupSCC(C1));
ASSERT_EQ(&CC, CG.lookupSCC(C2));
ASSERT_EQ(&CC, CG.lookupSCC(C3));
ASSERT_EQ(&DC, CG.lookupSCC(D1));
ASSERT_EQ(&DC, CG.lookupSCC(D2));
ASSERT_EQ(&DC, CG.lookupSCC(D3));
ASSERT_EQ(1, std::distance(D2.begin(), D2.end()));
CC.insertIncomingEdge(D2, C2);
EXPECT_EQ(2, std::distance(D2.begin(), D2.end()));
// Make sure we have the correct nodes in the SCC sets.
EXPECT_EQ(&CC, CG.lookupSCC(C1));
EXPECT_EQ(&CC, CG.lookupSCC(C2));
EXPECT_EQ(&CC, CG.lookupSCC(C3));
EXPECT_EQ(&CC, CG.lookupSCC(D1));
EXPECT_EQ(&CC, CG.lookupSCC(D2));
EXPECT_EQ(&CC, CG.lookupSCC(D3));
// Check that we can form the last two SCCs now in a coherent way.
++SCCI;
EXPECT_NE(SCCI, SCCE);
LazyCallGraph::SCC &BC = *SCCI;
EXPECT_NE(&BC, nullptr);
EXPECT_EQ(&BC, CG.lookupSCC(*CG.lookup(lookupFunction(*M, "b1"))));
EXPECT_EQ(&BC, CG.lookupSCC(*CG.lookup(lookupFunction(*M, "b2"))));
EXPECT_EQ(&BC, CG.lookupSCC(*CG.lookup(lookupFunction(*M, "b3"))));
++SCCI;
EXPECT_NE(SCCI, SCCE);
LazyCallGraph::SCC &AC = *SCCI;
EXPECT_NE(&AC, nullptr);
EXPECT_EQ(&AC, CG.lookupSCC(*CG.lookup(lookupFunction(*M, "a1"))));
EXPECT_EQ(&AC, CG.lookupSCC(*CG.lookup(lookupFunction(*M, "a2"))));
EXPECT_EQ(&AC, CG.lookupSCC(*CG.lookup(lookupFunction(*M, "a3"))));
++SCCI;
EXPECT_EQ(SCCI, SCCE);
}
[LCG] Add the first round of mutation support to the lazy call graph. This implements the core functionality necessary to remove an edge from the call graph and correctly update both the basic graph and the SCC structure. As part of that it has to run a tiny (in number of nodes) Tarjan-style DFS walk of an SCC being mutated to compute newly formed SCCs, etc. This is *very rough* and a WIP. I have a bunch of FIXMEs for code cleanup that will reduce the boilerplate in this change substantially. I also have a bunch of simplifications to various parts of both algorithms that I want to make, but first I'd like to have a more holistic picture. Ideally, I'd also like more testing. I'll probably add quite a few more unit tests as I go here to cover the various different aspects and corner cases of removing edges from the graph. Still, this is, so far, successfully updating the SCC graph in-place without disrupting the identity established for the existing SCCs even when we do challenging things like delete the critical edge that made an SCC cycle at all and have to reform things as a tree of smaller SCCs. Getting this to work is really critical for the new pass manager as it is going to associate significant state with the SCC instance and needs it to be stable. That is also the motivation behind the return of the newly formed SCCs. Eventually, I'll wire this all the way up to the public API so that the pass manager can use it to correctly re-enqueue newly formed SCCs into a fresh postorder traversal. llvm-svn: 206968
2014-04-23 19:03:03 +08:00
TEST(LazyCallGraphTest, InterSCCEdgeRemoval) {
std::unique_ptr<Module> M = parseAssembly(
"define void @a() {\n"
"entry:\n"
" call void @b()\n"
" ret void\n"
"}\n"
"define void @b() {\n"
"entry:\n"
" ret void\n"
"}\n");
LazyCallGraph CG(*M);
// Force the graph to be fully expanded.
[LCG] Normalize the post-order SCC iterator to just iterate over the SCC values rather than having pointers in weird places. llvm-svn: 207053
2014-04-24 07:51:07 +08:00
for (LazyCallGraph::SCC &C : CG.postorder_sccs())
[LCG] Add the first round of mutation support to the lazy call graph. This implements the core functionality necessary to remove an edge from the call graph and correctly update both the basic graph and the SCC structure. As part of that it has to run a tiny (in number of nodes) Tarjan-style DFS walk of an SCC being mutated to compute newly formed SCCs, etc. This is *very rough* and a WIP. I have a bunch of FIXMEs for code cleanup that will reduce the boilerplate in this change substantially. I also have a bunch of simplifications to various parts of both algorithms that I want to make, but first I'd like to have a more holistic picture. Ideally, I'd also like more testing. I'll probably add quite a few more unit tests as I go here to cover the various different aspects and corner cases of removing edges from the graph. Still, this is, so far, successfully updating the SCC graph in-place without disrupting the identity established for the existing SCCs even when we do challenging things like delete the critical edge that made an SCC cycle at all and have to reform things as a tree of smaller SCCs. Getting this to work is really critical for the new pass manager as it is going to associate significant state with the SCC instance and needs it to be stable. That is also the motivation behind the return of the newly formed SCCs. Eventually, I'll wire this all the way up to the public API so that the pass manager can use it to correctly re-enqueue newly formed SCCs into a fresh postorder traversal. llvm-svn: 206968
2014-04-23 19:03:03 +08:00
(void)C;
[LCG] Switch the SCC lookup to be in terms of call graph nodes rather than functions. So far, this access pattern is *much* more common. It seems likely that any user of this interface is going to have nodes at the point that they are querying the SCCs. No functionality changed. llvm-svn: 207045
2014-04-24 07:12:06 +08:00
LazyCallGraph::Node &A = *CG.lookup(lookupFunction(*M, "a"));
LazyCallGraph::Node &B = *CG.lookup(lookupFunction(*M, "b"));
LazyCallGraph::SCC &AC = *CG.lookupSCC(A);
LazyCallGraph::SCC &BC = *CG.lookupSCC(B);
[LCG] Add the first round of mutation support to the lazy call graph. This implements the core functionality necessary to remove an edge from the call graph and correctly update both the basic graph and the SCC structure. As part of that it has to run a tiny (in number of nodes) Tarjan-style DFS walk of an SCC being mutated to compute newly formed SCCs, etc. This is *very rough* and a WIP. I have a bunch of FIXMEs for code cleanup that will reduce the boilerplate in this change substantially. I also have a bunch of simplifications to various parts of both algorithms that I want to make, but first I'd like to have a more holistic picture. Ideally, I'd also like more testing. I'll probably add quite a few more unit tests as I go here to cover the various different aspects and corner cases of removing edges from the graph. Still, this is, so far, successfully updating the SCC graph in-place without disrupting the identity established for the existing SCCs even when we do challenging things like delete the critical edge that made an SCC cycle at all and have to reform things as a tree of smaller SCCs. Getting this to work is really critical for the new pass manager as it is going to associate significant state with the SCC instance and needs it to be stable. That is also the motivation behind the return of the newly formed SCCs. Eventually, I'll wire this all the way up to the public API so that the pass manager can use it to correctly re-enqueue newly formed SCCs into a fresh postorder traversal. llvm-svn: 206968
2014-04-23 19:03:03 +08:00
[LCG] Switch the SCC lookup to be in terms of call graph nodes rather than functions. So far, this access pattern is *much* more common. It seems likely that any user of this interface is going to have nodes at the point that they are querying the SCCs. No functionality changed. llvm-svn: 207045
2014-04-24 07:12:06 +08:00
EXPECT_EQ("b", A.begin()->getFunction().getName());
EXPECT_EQ(B.end(), B.begin());
[LCG] Switch the SCC's parent iterators to be value iterators rather than pointer iterators. llvm-svn: 207086
2014-04-24 15:48:18 +08:00
EXPECT_EQ(&AC, &*BC.parent_begin());
[LCG] Add the first round of mutation support to the lazy call graph. This implements the core functionality necessary to remove an edge from the call graph and correctly update both the basic graph and the SCC structure. As part of that it has to run a tiny (in number of nodes) Tarjan-style DFS walk of an SCC being mutated to compute newly formed SCCs, etc. This is *very rough* and a WIP. I have a bunch of FIXMEs for code cleanup that will reduce the boilerplate in this change substantially. I also have a bunch of simplifications to various parts of both algorithms that I want to make, but first I'd like to have a more holistic picture. Ideally, I'd also like more testing. I'll probably add quite a few more unit tests as I go here to cover the various different aspects and corner cases of removing edges from the graph. Still, this is, so far, successfully updating the SCC graph in-place without disrupting the identity established for the existing SCCs even when we do challenging things like delete the critical edge that made an SCC cycle at all and have to reform things as a tree of smaller SCCs. Getting this to work is really critical for the new pass manager as it is going to associate significant state with the SCC instance and needs it to be stable. That is also the motivation behind the return of the newly formed SCCs. Eventually, I'll wire this all the way up to the public API so that the pass manager can use it to correctly re-enqueue newly formed SCCs into a fresh postorder traversal. llvm-svn: 206968
2014-04-23 19:03:03 +08:00
[LCG] Re-organize the methods for mutating a call graph to make their API requirements much more obvious. The key here is that there are two totally different use cases for mutating the graph. Prior to doing any SCC formation, it is very easy to mutate the graph. There may be users that want to do small tweaks here, and then use the already-built graph for their SCC-based operations. This method remains on the graph itself and is documented carefully as being cheap but unavailable once SCCs are formed. Once SCCs are formed, and there is some in-flight DFS building them, we have to be much more careful in how we mutate the graph. These mutation operations are sunk onto the SCCs themselves, which both simplifies things (the code was already there!) and helps make it obvious that these interfaces are only applicable within that context. The other primary constraint is that the edge being mutated is actually related to the SCC on which we call the method. This helps make it obvious that you cannot arbitrarily mutate some other SCC. I've tried to write much more complete documentation for the interesting mutation API -- intra-SCC edge removal. Currently one aspect of this documentation is a lie (the result list of SCCs) but we also don't even have tests for that API. =[ I'm going to add tests and fix it to match the documentation next. llvm-svn: 207339
2014-04-27 09:59:50 +08:00
AC.removeInterSCCEdge(A, B);
[LCG] Add the first round of mutation support to the lazy call graph. This implements the core functionality necessary to remove an edge from the call graph and correctly update both the basic graph and the SCC structure. As part of that it has to run a tiny (in number of nodes) Tarjan-style DFS walk of an SCC being mutated to compute newly formed SCCs, etc. This is *very rough* and a WIP. I have a bunch of FIXMEs for code cleanup that will reduce the boilerplate in this change substantially. I also have a bunch of simplifications to various parts of both algorithms that I want to make, but first I'd like to have a more holistic picture. Ideally, I'd also like more testing. I'll probably add quite a few more unit tests as I go here to cover the various different aspects and corner cases of removing edges from the graph. Still, this is, so far, successfully updating the SCC graph in-place without disrupting the identity established for the existing SCCs even when we do challenging things like delete the critical edge that made an SCC cycle at all and have to reform things as a tree of smaller SCCs. Getting this to work is really critical for the new pass manager as it is going to associate significant state with the SCC instance and needs it to be stable. That is also the motivation behind the return of the newly formed SCCs. Eventually, I'll wire this all the way up to the public API so that the pass manager can use it to correctly re-enqueue newly formed SCCs into a fresh postorder traversal. llvm-svn: 206968
2014-04-23 19:03:03 +08:00
[LCG] Switch the SCC lookup to be in terms of call graph nodes rather than functions. So far, this access pattern is *much* more common. It seems likely that any user of this interface is going to have nodes at the point that they are querying the SCCs. No functionality changed. llvm-svn: 207045
2014-04-24 07:12:06 +08:00
EXPECT_EQ(A.end(), A.begin());
EXPECT_EQ(B.end(), B.begin());
EXPECT_EQ(BC.parent_end(), BC.parent_begin());
[LCG] Add the first round of mutation support to the lazy call graph. This implements the core functionality necessary to remove an edge from the call graph and correctly update both the basic graph and the SCC structure. As part of that it has to run a tiny (in number of nodes) Tarjan-style DFS walk of an SCC being mutated to compute newly formed SCCs, etc. This is *very rough* and a WIP. I have a bunch of FIXMEs for code cleanup that will reduce the boilerplate in this change substantially. I also have a bunch of simplifications to various parts of both algorithms that I want to make, but first I'd like to have a more holistic picture. Ideally, I'd also like more testing. I'll probably add quite a few more unit tests as I go here to cover the various different aspects and corner cases of removing edges from the graph. Still, this is, so far, successfully updating the SCC graph in-place without disrupting the identity established for the existing SCCs even when we do challenging things like delete the critical edge that made an SCC cycle at all and have to reform things as a tree of smaller SCCs. Getting this to work is really critical for the new pass manager as it is going to associate significant state with the SCC instance and needs it to be stable. That is also the motivation behind the return of the newly formed SCCs. Eventually, I'll wire this all the way up to the public API so that the pass manager can use it to correctly re-enqueue newly formed SCCs into a fresh postorder traversal. llvm-svn: 206968
2014-04-23 19:03:03 +08:00
}
[LCG] Add the really, *really* boring edge insertion case: adding an edge entirely within an existing SCC. Shockingly, making the connected component more connected is ... a total snooze fest. =] Anyways, its wired up, and I even added a test case to make sure it pretty much sorta works. =D llvm-svn: 207631
2014-04-30 18:48:36 +08:00
TEST(LazyCallGraphTest, IntraSCCEdgeInsertion) {
std::unique_ptr<Module> M1 = parseAssembly(
"define void @a() {\n"
"entry:\n"
" call void @b()\n"
" ret void\n"
"}\n"
"define void @b() {\n"
"entry:\n"
" call void @c()\n"
" ret void\n"
"}\n"
"define void @c() {\n"
"entry:\n"
" call void @a()\n"
" ret void\n"
"}\n");
LazyCallGraph CG1(*M1);
// Force the graph to be fully expanded.
auto SCCI = CG1.postorder_scc_begin();
LazyCallGraph::SCC &SCC = *SCCI++;
EXPECT_EQ(CG1.postorder_scc_end(), SCCI);
LazyCallGraph::Node &A = *CG1.lookup(lookupFunction(*M1, "a"));
LazyCallGraph::Node &B = *CG1.lookup(lookupFunction(*M1, "b"));
LazyCallGraph::Node &C = *CG1.lookup(lookupFunction(*M1, "c"));
EXPECT_EQ(&SCC, CG1.lookupSCC(A));
EXPECT_EQ(&SCC, CG1.lookupSCC(B));
EXPECT_EQ(&SCC, CG1.lookupSCC(C));
// Insert an edge from 'a' to 'c'. Nothing changes about the SCCs.
SCC.insertIntraSCCEdge(A, C);
EXPECT_EQ(2, std::distance(A.begin(), A.end()));
EXPECT_EQ(&SCC, CG1.lookupSCC(A));
EXPECT_EQ(&SCC, CG1.lookupSCC(B));
EXPECT_EQ(&SCC, CG1.lookupSCC(C));
// Insert a self edge from 'a' back to 'a'.
SCC.insertIntraSCCEdge(A, A);
EXPECT_EQ(3, std::distance(A.begin(), A.end()));
EXPECT_EQ(&SCC, CG1.lookupSCC(A));
EXPECT_EQ(&SCC, CG1.lookupSCC(B));
EXPECT_EQ(&SCC, CG1.lookupSCC(C));
}
[LCG] Add the first round of mutation support to the lazy call graph. This implements the core functionality necessary to remove an edge from the call graph and correctly update both the basic graph and the SCC structure. As part of that it has to run a tiny (in number of nodes) Tarjan-style DFS walk of an SCC being mutated to compute newly formed SCCs, etc. This is *very rough* and a WIP. I have a bunch of FIXMEs for code cleanup that will reduce the boilerplate in this change substantially. I also have a bunch of simplifications to various parts of both algorithms that I want to make, but first I'd like to have a more holistic picture. Ideally, I'd also like more testing. I'll probably add quite a few more unit tests as I go here to cover the various different aspects and corner cases of removing edges from the graph. Still, this is, so far, successfully updating the SCC graph in-place without disrupting the identity established for the existing SCCs even when we do challenging things like delete the critical edge that made an SCC cycle at all and have to reform things as a tree of smaller SCCs. Getting this to work is really critical for the new pass manager as it is going to associate significant state with the SCC instance and needs it to be stable. That is also the motivation behind the return of the newly formed SCCs. Eventually, I'll wire this all the way up to the public API so that the pass manager can use it to correctly re-enqueue newly formed SCCs into a fresh postorder traversal. llvm-svn: 206968
2014-04-23 19:03:03 +08:00
TEST(LazyCallGraphTest, IntraSCCEdgeRemoval) {
// A nice fully connected (including self-edges) SCC.
std::unique_ptr<Module> M1 = parseAssembly(
"define void @a() {\n"
"entry:\n"
" call void @a()\n"
" call void @b()\n"
" call void @c()\n"
" ret void\n"
"}\n"
"define void @b() {\n"
"entry:\n"
" call void @a()\n"
" call void @b()\n"
" call void @c()\n"
" ret void\n"
"}\n"
"define void @c() {\n"
"entry:\n"
" call void @a()\n"
" call void @b()\n"
" call void @c()\n"
" ret void\n"
"}\n");
LazyCallGraph CG1(*M1);
// Force the graph to be fully expanded.
auto SCCI = CG1.postorder_scc_begin();
[LCG] Normalize the post-order SCC iterator to just iterate over the SCC values rather than having pointers in weird places. llvm-svn: 207053
2014-04-24 07:51:07 +08:00
LazyCallGraph::SCC &SCC = *SCCI++;
[LCG] Add the first round of mutation support to the lazy call graph. This implements the core functionality necessary to remove an edge from the call graph and correctly update both the basic graph and the SCC structure. As part of that it has to run a tiny (in number of nodes) Tarjan-style DFS walk of an SCC being mutated to compute newly formed SCCs, etc. This is *very rough* and a WIP. I have a bunch of FIXMEs for code cleanup that will reduce the boilerplate in this change substantially. I also have a bunch of simplifications to various parts of both algorithms that I want to make, but first I'd like to have a more holistic picture. Ideally, I'd also like more testing. I'll probably add quite a few more unit tests as I go here to cover the various different aspects and corner cases of removing edges from the graph. Still, this is, so far, successfully updating the SCC graph in-place without disrupting the identity established for the existing SCCs even when we do challenging things like delete the critical edge that made an SCC cycle at all and have to reform things as a tree of smaller SCCs. Getting this to work is really critical for the new pass manager as it is going to associate significant state with the SCC instance and needs it to be stable. That is also the motivation behind the return of the newly formed SCCs. Eventually, I'll wire this all the way up to the public API so that the pass manager can use it to correctly re-enqueue newly formed SCCs into a fresh postorder traversal. llvm-svn: 206968
2014-04-23 19:03:03 +08:00
EXPECT_EQ(CG1.postorder_scc_end(), SCCI);
[LCG] Switch the SCC lookup to be in terms of call graph nodes rather than functions. So far, this access pattern is *much* more common. It seems likely that any user of this interface is going to have nodes at the point that they are querying the SCCs. No functionality changed. llvm-svn: 207045
2014-04-24 07:12:06 +08:00
LazyCallGraph::Node &A = *CG1.lookup(lookupFunction(*M1, "a"));
LazyCallGraph::Node &B = *CG1.lookup(lookupFunction(*M1, "b"));
LazyCallGraph::Node &C = *CG1.lookup(lookupFunction(*M1, "c"));
[LCG] Normalize the post-order SCC iterator to just iterate over the SCC values rather than having pointers in weird places. llvm-svn: 207053
2014-04-24 07:51:07 +08:00
EXPECT_EQ(&SCC, CG1.lookupSCC(A));
EXPECT_EQ(&SCC, CG1.lookupSCC(B));
EXPECT_EQ(&SCC, CG1.lookupSCC(C));
[LCG] Add the first round of mutation support to the lazy call graph. This implements the core functionality necessary to remove an edge from the call graph and correctly update both the basic graph and the SCC structure. As part of that it has to run a tiny (in number of nodes) Tarjan-style DFS walk of an SCC being mutated to compute newly formed SCCs, etc. This is *very rough* and a WIP. I have a bunch of FIXMEs for code cleanup that will reduce the boilerplate in this change substantially. I also have a bunch of simplifications to various parts of both algorithms that I want to make, but first I'd like to have a more holistic picture. Ideally, I'd also like more testing. I'll probably add quite a few more unit tests as I go here to cover the various different aspects and corner cases of removing edges from the graph. Still, this is, so far, successfully updating the SCC graph in-place without disrupting the identity established for the existing SCCs even when we do challenging things like delete the critical edge that made an SCC cycle at all and have to reform things as a tree of smaller SCCs. Getting this to work is really critical for the new pass manager as it is going to associate significant state with the SCC instance and needs it to be stable. That is also the motivation behind the return of the newly formed SCCs. Eventually, I'll wire this all the way up to the public API so that the pass manager can use it to correctly re-enqueue newly formed SCCs into a fresh postorder traversal. llvm-svn: 206968
2014-04-23 19:03:03 +08:00
// Remove the edge from b -> a, which should leave the 3 functions still in
// a single connected component because of a -> b -> c -> a.
[LCG] Make the return of the IntraSCC removal method actually match its contract (and be much more useful). It now provides exactly the post-order traversal a caller might need to perform on newly formed SCCs. llvm-svn: 207410
2014-04-28 18:49:06 +08:00
SmallVector<LazyCallGraph::SCC *, 1> NewSCCs = SCC.removeIntraSCCEdge(B, A);
EXPECT_EQ(0u, NewSCCs.size());
[LCG] Normalize the post-order SCC iterator to just iterate over the SCC values rather than having pointers in weird places. llvm-svn: 207053
2014-04-24 07:51:07 +08:00
EXPECT_EQ(&SCC, CG1.lookupSCC(A));
EXPECT_EQ(&SCC, CG1.lookupSCC(B));
EXPECT_EQ(&SCC, CG1.lookupSCC(C));
[LCG] Add the first round of mutation support to the lazy call graph. This implements the core functionality necessary to remove an edge from the call graph and correctly update both the basic graph and the SCC structure. As part of that it has to run a tiny (in number of nodes) Tarjan-style DFS walk of an SCC being mutated to compute newly formed SCCs, etc. This is *very rough* and a WIP. I have a bunch of FIXMEs for code cleanup that will reduce the boilerplate in this change substantially. I also have a bunch of simplifications to various parts of both algorithms that I want to make, but first I'd like to have a more holistic picture. Ideally, I'd also like more testing. I'll probably add quite a few more unit tests as I go here to cover the various different aspects and corner cases of removing edges from the graph. Still, this is, so far, successfully updating the SCC graph in-place without disrupting the identity established for the existing SCCs even when we do challenging things like delete the critical edge that made an SCC cycle at all and have to reform things as a tree of smaller SCCs. Getting this to work is really critical for the new pass manager as it is going to associate significant state with the SCC instance and needs it to be stable. That is also the motivation behind the return of the newly formed SCCs. Eventually, I'll wire this all the way up to the public API so that the pass manager can use it to correctly re-enqueue newly formed SCCs into a fresh postorder traversal. llvm-svn: 206968
2014-04-23 19:03:03 +08:00
// Remove the edge from c -> a, which should leave 'a' in the original SCC
// and form a new SCC for 'b' and 'c'.
[LCG] Make the return of the IntraSCC removal method actually match its contract (and be much more useful). It now provides exactly the post-order traversal a caller might need to perform on newly formed SCCs. llvm-svn: 207410
2014-04-28 18:49:06 +08:00
NewSCCs = SCC.removeIntraSCCEdge(C, A);
EXPECT_EQ(1u, NewSCCs.size());
[LCG] Normalize the post-order SCC iterator to just iterate over the SCC values rather than having pointers in weird places. llvm-svn: 207053
2014-04-24 07:51:07 +08:00
EXPECT_EQ(&SCC, CG1.lookupSCC(A));
EXPECT_EQ(1, std::distance(SCC.begin(), SCC.end()));
[LCG] Switch the SCC lookup to be in terms of call graph nodes rather than functions. So far, this access pattern is *much* more common. It seems likely that any user of this interface is going to have nodes at the point that they are querying the SCCs. No functionality changed. llvm-svn: 207045
2014-04-24 07:12:06 +08:00
LazyCallGraph::SCC *SCC2 = CG1.lookupSCC(B);
EXPECT_EQ(SCC2, CG1.lookupSCC(C));
[LCG] Make the return of the IntraSCC removal method actually match its contract (and be much more useful). It now provides exactly the post-order traversal a caller might need to perform on newly formed SCCs. llvm-svn: 207410
2014-04-28 18:49:06 +08:00
EXPECT_EQ(SCC2, NewSCCs[0]);
[LCG] Add the first round of mutation support to the lazy call graph. This implements the core functionality necessary to remove an edge from the call graph and correctly update both the basic graph and the SCC structure. As part of that it has to run a tiny (in number of nodes) Tarjan-style DFS walk of an SCC being mutated to compute newly formed SCCs, etc. This is *very rough* and a WIP. I have a bunch of FIXMEs for code cleanup that will reduce the boilerplate in this change substantially. I also have a bunch of simplifications to various parts of both algorithms that I want to make, but first I'd like to have a more holistic picture. Ideally, I'd also like more testing. I'll probably add quite a few more unit tests as I go here to cover the various different aspects and corner cases of removing edges from the graph. Still, this is, so far, successfully updating the SCC graph in-place without disrupting the identity established for the existing SCCs even when we do challenging things like delete the critical edge that made an SCC cycle at all and have to reform things as a tree of smaller SCCs. Getting this to work is really critical for the new pass manager as it is going to associate significant state with the SCC instance and needs it to be stable. That is also the motivation behind the return of the newly formed SCCs. Eventually, I'll wire this all the way up to the public API so that the pass manager can use it to correctly re-enqueue newly formed SCCs into a fresh postorder traversal. llvm-svn: 206968
2014-04-23 19:03:03 +08:00
}
[LCG] Add a unittest for the LazyCallGraph. I had a weak moment and resisted this for too long. Just with the basic testing here I was able to exercise the analysis in more detail and sift out both type signature bugs in the API and a bug in the DFS numbering. All of these are fixed here as well. The unittests will be much more important for the mutation support where it is necessary to craft minimal mutations and then inspect the state of the graph. There is just no way to do that with a standard FileCheck test. However, unittesting these kinds of analyses is really quite easy, especially as they're designed with the new pass manager where there is essentially no infrastructure required to rig up the core logic and exercise it at an API level. As a minor aside about the DFS numbering bug, the DFS numbering used in LCG is a bit unusual. Rather than numbering from 0, we number from 1, and use 0 as the sentinel "unvisited" state. Other implementations often use '-1' for this, but I find it easier to deal with 0 and it shouldn't make any real difference provided someone doesn't write silly bugs like forgetting to actually initialize the DFS numbering. Oops. ;] llvm-svn: 206954
2014-04-23 16:08:49 +08:00
}