Data Dependence Graph Basics
Summary:
This is the first patch in a series of patches that will implement data dependence graph in LLVM. Many of the ideas used in this implementation are based on the following paper:
D. J. Kuck, R. H. Kuhn, D. A. Padua, B. Leasure, and M. Wolfe (1981). DEPENDENCE GRAPHS AND COMPILER OPTIMIZATIONS.
This patch contains support for a basic DDGs containing only atomic nodes (one node for each instruction). The edges are two fold: def-use edges and memory-dependence edges.
The implementation takes a list of basic-blocks and only considers dependencies among instructions in those basic blocks. Any dependencies coming into or going out of instructions that do not belong to those basic blocks are ignored.
The algorithm for building the graph involves the following steps in order:
1. For each instruction in the range of basic blocks to consider, create an atomic node in the resulting graph.
2. For each node in the graph establish def-use edges to/from other nodes in the graph.
3. For each pair of nodes containing memory instruction(s) create memory edges between them. This part of the algorithm goes through the instructions in lexicographical order and creates edges in reverse order if the sink of the dependence occurs before the source of it.
Authored By: bmahjour
Reviewer: Meinersbur, fhahn, myhsu, xtian, dmgreen, kbarton, jdoerfert
Reviewed By: Meinersbur, fhahn, myhsu
Subscribers: ychen, arphaman, simoll, a.elovikov, mgorny, hiraditya, jfb, wuzish, llvm-commits, jsji, Whitney, etiotto
Tag: #llvm
Differential Revision: https://reviews.llvm.org/D65350
llvm-svn: 372238
2019-09-18 19:43:45 +02:00
|
|
|
//===- DependenceGraphBuilder.cpp ------------------------------------------==//
|
|
|
|
//
|
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// This file implements common steps of the build algorithm for construction
|
|
|
|
// of dependence graphs such as DDG and PDG.
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "llvm/Analysis/DependenceGraphBuilder.h"
|
2020-06-06 15:06:25 +02:00
|
|
|
#include "llvm/ADT/DepthFirstIterator.h"
|
[DDG] Data Dependence Graph - Pi Block
Summary:
This patch adds Pi Blocks to the DDG. A pi-block represents a group of DDG
nodes that are part of a strongly-connected component of the graph.
Replacing all the SCCs with pi-blocks results in an acyclic representation
of the DDG. For example if we have:
{a -> b}, {b -> c, d}, {c -> a}
the cycle a -> b -> c -> a is abstracted into a pi-block "p" as follows:
{p -> d} with "p" containing: {a -> b}, {b -> c}, {c -> a}
In this implementation the edges between nodes that are part of the pi-block
are preserved. The crossing edges (edges where one end of the edge is in the
set of nodes belonging to an SCC and the other end is outside that set) are
replaced with corresponding edges to/from the pi-block node instead.
Authored By: bmahjour
Reviewer: Meinersbur, fhahn, myhsu, xtian, dmgreen, kbarton, jdoerfert
Reviewed By: Meinersbur
Subscribers: ychen, arphaman, simoll, a.elovikov, mgorny, hiraditya, jfb, wuzish, llvm-commits, jsji, Whitney, etiotto, ppc-slack
Tag: #llvm
Differential Revision: https://reviews.llvm.org/D68827
2019-11-08 21:05:06 +01:00
|
|
|
#include "llvm/ADT/EnumeratedArray.h"
|
Data Dependence Graph Basics
Summary:
This is the first patch in a series of patches that will implement data dependence graph in LLVM. Many of the ideas used in this implementation are based on the following paper:
D. J. Kuck, R. H. Kuhn, D. A. Padua, B. Leasure, and M. Wolfe (1981). DEPENDENCE GRAPHS AND COMPILER OPTIMIZATIONS.
This patch contains support for a basic DDGs containing only atomic nodes (one node for each instruction). The edges are two fold: def-use edges and memory-dependence edges.
The implementation takes a list of basic-blocks and only considers dependencies among instructions in those basic blocks. Any dependencies coming into or going out of instructions that do not belong to those basic blocks are ignored.
The algorithm for building the graph involves the following steps in order:
1. For each instruction in the range of basic blocks to consider, create an atomic node in the resulting graph.
2. For each node in the graph establish def-use edges to/from other nodes in the graph.
3. For each pair of nodes containing memory instruction(s) create memory edges between them. This part of the algorithm goes through the instructions in lexicographical order and creates edges in reverse order if the sink of the dependence occurs before the source of it.
Authored By: bmahjour
Reviewer: Meinersbur, fhahn, myhsu, xtian, dmgreen, kbarton, jdoerfert
Reviewed By: Meinersbur, fhahn, myhsu
Subscribers: ychen, arphaman, simoll, a.elovikov, mgorny, hiraditya, jfb, wuzish, llvm-commits, jsji, Whitney, etiotto
Tag: #llvm
Differential Revision: https://reviews.llvm.org/D65350
llvm-svn: 372238
2019-09-18 19:43:45 +02:00
|
|
|
#include "llvm/ADT/SCCIterator.h"
|
|
|
|
#include "llvm/ADT/Statistic.h"
|
|
|
|
#include "llvm/Analysis/DDG.h"
|
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
|
|
|
|
#define DEBUG_TYPE "dgb"
|
|
|
|
|
|
|
|
STATISTIC(TotalGraphs, "Number of dependence graphs created.");
|
|
|
|
STATISTIC(TotalDefUseEdges, "Number of def-use edges created.");
|
|
|
|
STATISTIC(TotalMemoryEdges, "Number of memory dependence edges created.");
|
|
|
|
STATISTIC(TotalFineGrainedNodes, "Number of fine-grained nodes created.");
|
[DDG] Data Dependence Graph - Pi Block
Summary:
This patch adds Pi Blocks to the DDG. A pi-block represents a group of DDG
nodes that are part of a strongly-connected component of the graph.
Replacing all the SCCs with pi-blocks results in an acyclic representation
of the DDG. For example if we have:
{a -> b}, {b -> c, d}, {c -> a}
the cycle a -> b -> c -> a is abstracted into a pi-block "p" as follows:
{p -> d} with "p" containing: {a -> b}, {b -> c}, {c -> a}
In this implementation the edges between nodes that are part of the pi-block
are preserved. The crossing edges (edges where one end of the edge is in the
set of nodes belonging to an SCC and the other end is outside that set) are
replaced with corresponding edges to/from the pi-block node instead.
Authored By: bmahjour
Reviewer: Meinersbur, fhahn, myhsu, xtian, dmgreen, kbarton, jdoerfert
Reviewed By: Meinersbur
Subscribers: ychen, arphaman, simoll, a.elovikov, mgorny, hiraditya, jfb, wuzish, llvm-commits, jsji, Whitney, etiotto, ppc-slack
Tag: #llvm
Differential Revision: https://reviews.llvm.org/D68827
2019-11-08 21:05:06 +01:00
|
|
|
STATISTIC(TotalPiBlockNodes, "Number of pi-block nodes created.");
|
Data Dependence Graph Basics
Summary:
This is the first patch in a series of patches that will implement data dependence graph in LLVM. Many of the ideas used in this implementation are based on the following paper:
D. J. Kuck, R. H. Kuhn, D. A. Padua, B. Leasure, and M. Wolfe (1981). DEPENDENCE GRAPHS AND COMPILER OPTIMIZATIONS.
This patch contains support for a basic DDGs containing only atomic nodes (one node for each instruction). The edges are two fold: def-use edges and memory-dependence edges.
The implementation takes a list of basic-blocks and only considers dependencies among instructions in those basic blocks. Any dependencies coming into or going out of instructions that do not belong to those basic blocks are ignored.
The algorithm for building the graph involves the following steps in order:
1. For each instruction in the range of basic blocks to consider, create an atomic node in the resulting graph.
2. For each node in the graph establish def-use edges to/from other nodes in the graph.
3. For each pair of nodes containing memory instruction(s) create memory edges between them. This part of the algorithm goes through the instructions in lexicographical order and creates edges in reverse order if the sink of the dependence occurs before the source of it.
Authored By: bmahjour
Reviewer: Meinersbur, fhahn, myhsu, xtian, dmgreen, kbarton, jdoerfert
Reviewed By: Meinersbur, fhahn, myhsu
Subscribers: ychen, arphaman, simoll, a.elovikov, mgorny, hiraditya, jfb, wuzish, llvm-commits, jsji, Whitney, etiotto
Tag: #llvm
Differential Revision: https://reviews.llvm.org/D65350
llvm-svn: 372238
2019-09-18 19:43:45 +02:00
|
|
|
STATISTIC(TotalConfusedEdges,
|
|
|
|
"Number of confused memory dependencies between two nodes.");
|
|
|
|
STATISTIC(TotalEdgeReversals,
|
|
|
|
"Number of times the source and sink of dependence was reversed to "
|
|
|
|
"expose cycles in the graph.");
|
|
|
|
|
|
|
|
using InstructionListType = SmallVector<Instruction *, 2>;
|
|
|
|
|
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
// AbstractDependenceGraphBuilder implementation
|
|
|
|
//===--------------------------------------------------------------------===//
|
|
|
|
|
[DDG] Data Dependence Graph - Ordinals
Summary:
This patch associates ordinal numbers to the DDG Nodes allowing
the builder to order nodes within a pi-block in program order. The
algorithm works by simply assuming the order in which the BBList
is fed into the builder. The builder already relies on the blocks being
in program order so that it can compute the dependencies correctly.
Similarly the order of instructions in their parent basic blocks
determine their program order.
Authored By: bmahjour
Reviewer: Meinersbur, fhahn, myhsu, xtian, dmgreen, kbarton, jdoerfert
Reviewed By: Meinersbur
Subscribers: ychen, arphaman, simoll, a.elovikov, mgorny, hiraditya, jfb, wuzish, llvm-commits, jsji, Whitney, etiotto, ppc-slack
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70986
2019-12-19 16:56:44 +01:00
|
|
|
template <class G>
|
|
|
|
void AbstractDependenceGraphBuilder<G>::computeInstructionOrdinals() {
|
|
|
|
// The BBList is expected to be in program order.
|
|
|
|
size_t NextOrdinal = 1;
|
|
|
|
for (auto *BB : BBList)
|
|
|
|
for (auto &I : *BB)
|
|
|
|
InstOrdinalMap.insert(std::make_pair(&I, NextOrdinal++));
|
|
|
|
}
|
|
|
|
|
Data Dependence Graph Basics
Summary:
This is the first patch in a series of patches that will implement data dependence graph in LLVM. Many of the ideas used in this implementation are based on the following paper:
D. J. Kuck, R. H. Kuhn, D. A. Padua, B. Leasure, and M. Wolfe (1981). DEPENDENCE GRAPHS AND COMPILER OPTIMIZATIONS.
This patch contains support for a basic DDGs containing only atomic nodes (one node for each instruction). The edges are two fold: def-use edges and memory-dependence edges.
The implementation takes a list of basic-blocks and only considers dependencies among instructions in those basic blocks. Any dependencies coming into or going out of instructions that do not belong to those basic blocks are ignored.
The algorithm for building the graph involves the following steps in order:
1. For each instruction in the range of basic blocks to consider, create an atomic node in the resulting graph.
2. For each node in the graph establish def-use edges to/from other nodes in the graph.
3. For each pair of nodes containing memory instruction(s) create memory edges between them. This part of the algorithm goes through the instructions in lexicographical order and creates edges in reverse order if the sink of the dependence occurs before the source of it.
Authored By: bmahjour
Reviewer: Meinersbur, fhahn, myhsu, xtian, dmgreen, kbarton, jdoerfert
Reviewed By: Meinersbur, fhahn, myhsu
Subscribers: ychen, arphaman, simoll, a.elovikov, mgorny, hiraditya, jfb, wuzish, llvm-commits, jsji, Whitney, etiotto
Tag: #llvm
Differential Revision: https://reviews.llvm.org/D65350
llvm-svn: 372238
2019-09-18 19:43:45 +02:00
|
|
|
template <class G>
|
|
|
|
void AbstractDependenceGraphBuilder<G>::createFineGrainedNodes() {
|
|
|
|
++TotalGraphs;
|
|
|
|
assert(IMap.empty() && "Expected empty instruction map at start");
|
|
|
|
for (BasicBlock *BB : BBList)
|
|
|
|
for (Instruction &I : *BB) {
|
|
|
|
auto &NewNode = createFineGrainedNode(I);
|
|
|
|
IMap.insert(std::make_pair(&I, &NewNode));
|
[DDG] Data Dependence Graph - Ordinals
Summary:
This patch associates ordinal numbers to the DDG Nodes allowing
the builder to order nodes within a pi-block in program order. The
algorithm works by simply assuming the order in which the BBList
is fed into the builder. The builder already relies on the blocks being
in program order so that it can compute the dependencies correctly.
Similarly the order of instructions in their parent basic blocks
determine their program order.
Authored By: bmahjour
Reviewer: Meinersbur, fhahn, myhsu, xtian, dmgreen, kbarton, jdoerfert
Reviewed By: Meinersbur
Subscribers: ychen, arphaman, simoll, a.elovikov, mgorny, hiraditya, jfb, wuzish, llvm-commits, jsji, Whitney, etiotto, ppc-slack
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70986
2019-12-19 16:56:44 +01:00
|
|
|
NodeOrdinalMap.insert(std::make_pair(&NewNode, getOrdinal(I)));
|
Data Dependence Graph Basics
Summary:
This is the first patch in a series of patches that will implement data dependence graph in LLVM. Many of the ideas used in this implementation are based on the following paper:
D. J. Kuck, R. H. Kuhn, D. A. Padua, B. Leasure, and M. Wolfe (1981). DEPENDENCE GRAPHS AND COMPILER OPTIMIZATIONS.
This patch contains support for a basic DDGs containing only atomic nodes (one node for each instruction). The edges are two fold: def-use edges and memory-dependence edges.
The implementation takes a list of basic-blocks and only considers dependencies among instructions in those basic blocks. Any dependencies coming into or going out of instructions that do not belong to those basic blocks are ignored.
The algorithm for building the graph involves the following steps in order:
1. For each instruction in the range of basic blocks to consider, create an atomic node in the resulting graph.
2. For each node in the graph establish def-use edges to/from other nodes in the graph.
3. For each pair of nodes containing memory instruction(s) create memory edges between them. This part of the algorithm goes through the instructions in lexicographical order and creates edges in reverse order if the sink of the dependence occurs before the source of it.
Authored By: bmahjour
Reviewer: Meinersbur, fhahn, myhsu, xtian, dmgreen, kbarton, jdoerfert
Reviewed By: Meinersbur, fhahn, myhsu
Subscribers: ychen, arphaman, simoll, a.elovikov, mgorny, hiraditya, jfb, wuzish, llvm-commits, jsji, Whitney, etiotto
Tag: #llvm
Differential Revision: https://reviews.llvm.org/D65350
llvm-svn: 372238
2019-09-18 19:43:45 +02:00
|
|
|
++TotalFineGrainedNodes;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
[DDG] Data Dependence Graph - Root Node
Summary:
This patch adds Root Node to the DDG. The purpose of the root node is to create a single entry node that allows graph walk iterators to iterate through all nodes of the graph, making sure that no node is left unvisited during a graph walk (eg. SCC or DFS). Once the DDG is fully constructed it will have exactly one root node. Every node in the graph is reachable from the root. The algorithm for connecting the root node is based on depth-first-search that keeps track of visited nodes to try to avoid creating unnecessary edges.
Authored By: bmahjour
Reviewer: Meinersbur, fhahn, myhsu, xtian, dmgreen, kbarton, jdoerfert
Reviewed By: Meinersbur
Subscribers: ychen, arphaman, simoll, a.elovikov, mgorny, hiraditya, jfb, wuzish, llvm-commits, jsji, Whitney, etiotto, ppc-slack
Tag: #llvm
Differential Revision: https://reviews.llvm.org/D67970
llvm-svn: 373386
2019-10-01 21:32:42 +02:00
|
|
|
template <class G>
|
|
|
|
void AbstractDependenceGraphBuilder<G>::createAndConnectRootNode() {
|
|
|
|
// Create a root node that connects to every connected component of the graph.
|
|
|
|
// This is done to allow graph iterators to visit all the disjoint components
|
|
|
|
// of the graph, in a single walk.
|
|
|
|
//
|
|
|
|
// This algorithm works by going through each node of the graph and for each
|
|
|
|
// node N, do a DFS starting from N. A rooted edge is established between the
|
|
|
|
// root node and N (if N is not yet visited). All the nodes reachable from N
|
|
|
|
// are marked as visited and are skipped in the DFS of subsequent nodes.
|
|
|
|
//
|
|
|
|
// Note: This algorithm tries to limit the number of edges out of the root
|
|
|
|
// node to some extent, but there may be redundant edges created depending on
|
|
|
|
// the iteration order. For example for a graph {A -> B}, an edge from the
|
|
|
|
// root node is added to both nodes if B is visited before A. While it does
|
|
|
|
// not result in minimal number of edges, this approach saves compile-time
|
|
|
|
// while keeping the number of edges in check.
|
|
|
|
auto &RootNode = createRootNode();
|
|
|
|
df_iterator_default_set<const NodeType *, 4> Visited;
|
|
|
|
for (auto *N : Graph) {
|
|
|
|
if (*N == RootNode)
|
|
|
|
continue;
|
|
|
|
for (auto I : depth_first_ext(N, Visited))
|
|
|
|
if (I == N)
|
|
|
|
createRootedEdge(RootNode, *N);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
[DDG] Data Dependence Graph - Pi Block
Summary:
This patch adds Pi Blocks to the DDG. A pi-block represents a group of DDG
nodes that are part of a strongly-connected component of the graph.
Replacing all the SCCs with pi-blocks results in an acyclic representation
of the DDG. For example if we have:
{a -> b}, {b -> c, d}, {c -> a}
the cycle a -> b -> c -> a is abstracted into a pi-block "p" as follows:
{p -> d} with "p" containing: {a -> b}, {b -> c}, {c -> a}
In this implementation the edges between nodes that are part of the pi-block
are preserved. The crossing edges (edges where one end of the edge is in the
set of nodes belonging to an SCC and the other end is outside that set) are
replaced with corresponding edges to/from the pi-block node instead.
Authored By: bmahjour
Reviewer: Meinersbur, fhahn, myhsu, xtian, dmgreen, kbarton, jdoerfert
Reviewed By: Meinersbur
Subscribers: ychen, arphaman, simoll, a.elovikov, mgorny, hiraditya, jfb, wuzish, llvm-commits, jsji, Whitney, etiotto, ppc-slack
Tag: #llvm
Differential Revision: https://reviews.llvm.org/D68827
2019-11-08 21:05:06 +01:00
|
|
|
template <class G> void AbstractDependenceGraphBuilder<G>::createPiBlocks() {
|
|
|
|
if (!shouldCreatePiBlocks())
|
|
|
|
return;
|
|
|
|
|
|
|
|
LLVM_DEBUG(dbgs() << "==== Start of Creation of Pi-Blocks ===\n");
|
|
|
|
|
|
|
|
// The overall algorithm is as follows:
|
|
|
|
// 1. Identify SCCs and for each SCC create a pi-block node containing all
|
|
|
|
// the nodes in that SCC.
|
|
|
|
// 2. Identify incoming edges incident to the nodes inside of the SCC and
|
|
|
|
// reconnect them to the pi-block node.
|
|
|
|
// 3. Identify outgoing edges from the nodes inside of the SCC to nodes
|
|
|
|
// outside of it and reconnect them so that the edges are coming out of the
|
|
|
|
// SCC node instead.
|
|
|
|
|
|
|
|
// Adding nodes as we iterate through the SCCs cause the SCC
|
|
|
|
// iterators to get invalidated. To prevent this invalidation, we first
|
|
|
|
// collect a list of nodes that are part of an SCC, and then iterate over
|
|
|
|
// those lists to create the pi-block nodes. Each element of the list is a
|
|
|
|
// list of nodes in an SCC. Note: trivial SCCs containing a single node are
|
|
|
|
// ignored.
|
|
|
|
SmallVector<NodeListType, 4> ListOfSCCs;
|
|
|
|
for (auto &SCC : make_range(scc_begin(&Graph), scc_end(&Graph))) {
|
|
|
|
if (SCC.size() > 1)
|
|
|
|
ListOfSCCs.emplace_back(SCC.begin(), SCC.end());
|
|
|
|
}
|
|
|
|
|
|
|
|
for (NodeListType &NL : ListOfSCCs) {
|
|
|
|
LLVM_DEBUG(dbgs() << "Creating pi-block node with " << NL.size()
|
|
|
|
<< " nodes in it.\n");
|
|
|
|
|
[DDG] Data Dependence Graph - Ordinals
Summary:
This patch associates ordinal numbers to the DDG Nodes allowing
the builder to order nodes within a pi-block in program order. The
algorithm works by simply assuming the order in which the BBList
is fed into the builder. The builder already relies on the blocks being
in program order so that it can compute the dependencies correctly.
Similarly the order of instructions in their parent basic blocks
determine their program order.
Authored By: bmahjour
Reviewer: Meinersbur, fhahn, myhsu, xtian, dmgreen, kbarton, jdoerfert
Reviewed By: Meinersbur
Subscribers: ychen, arphaman, simoll, a.elovikov, mgorny, hiraditya, jfb, wuzish, llvm-commits, jsji, Whitney, etiotto, ppc-slack
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70986
2019-12-19 16:56:44 +01:00
|
|
|
// SCC iterator may put the nodes in an order that's different from the
|
|
|
|
// program order. To preserve original program order, we sort the list of
|
|
|
|
// nodes based on ordinal numbers computed earlier.
|
|
|
|
llvm::sort(NL, [&](NodeType *LHS, NodeType *RHS) {
|
|
|
|
return getOrdinal(*LHS) < getOrdinal(*RHS);
|
|
|
|
});
|
|
|
|
|
[DDG] Data Dependence Graph - Pi Block
Summary:
This patch adds Pi Blocks to the DDG. A pi-block represents a group of DDG
nodes that are part of a strongly-connected component of the graph.
Replacing all the SCCs with pi-blocks results in an acyclic representation
of the DDG. For example if we have:
{a -> b}, {b -> c, d}, {c -> a}
the cycle a -> b -> c -> a is abstracted into a pi-block "p" as follows:
{p -> d} with "p" containing: {a -> b}, {b -> c}, {c -> a}
In this implementation the edges between nodes that are part of the pi-block
are preserved. The crossing edges (edges where one end of the edge is in the
set of nodes belonging to an SCC and the other end is outside that set) are
replaced with corresponding edges to/from the pi-block node instead.
Authored By: bmahjour
Reviewer: Meinersbur, fhahn, myhsu, xtian, dmgreen, kbarton, jdoerfert
Reviewed By: Meinersbur
Subscribers: ychen, arphaman, simoll, a.elovikov, mgorny, hiraditya, jfb, wuzish, llvm-commits, jsji, Whitney, etiotto, ppc-slack
Tag: #llvm
Differential Revision: https://reviews.llvm.org/D68827
2019-11-08 21:05:06 +01:00
|
|
|
NodeType &PiNode = createPiBlock(NL);
|
|
|
|
++TotalPiBlockNodes;
|
|
|
|
|
|
|
|
// Build a set to speed up the lookup for edges whose targets
|
|
|
|
// are inside the SCC.
|
|
|
|
SmallPtrSet<NodeType *, 4> NodesInSCC(NL.begin(), NL.end());
|
|
|
|
|
|
|
|
// We have the set of nodes in the SCC. We go through the set of nodes
|
|
|
|
// that are outside of the SCC and look for edges that cross the two sets.
|
|
|
|
for (NodeType *N : Graph) {
|
|
|
|
|
|
|
|
// Skip the SCC node and all the nodes inside of it.
|
|
|
|
if (*N == PiNode || NodesInSCC.count(N))
|
|
|
|
continue;
|
|
|
|
|
2021-01-07 16:31:11 +01:00
|
|
|
enum Direction {
|
|
|
|
Incoming, // Incoming edges to the SCC
|
|
|
|
Outgoing, // Edges going ot of the SCC
|
|
|
|
DirectionCount // To make the enum usable as an array index.
|
|
|
|
};
|
|
|
|
|
|
|
|
// Use these flags to help us avoid creating redundant edges. If there
|
|
|
|
// are more than one edges from an outside node to inside nodes, we only
|
|
|
|
// keep one edge from that node to the pi-block node. Similarly, if
|
|
|
|
// there are more than one edges from inside nodes to an outside node,
|
|
|
|
// we only keep one edge from the pi-block node to the outside node.
|
|
|
|
// There is a flag defined for each direction (incoming vs outgoing) and
|
|
|
|
// for each type of edge supported, using a two-dimensional boolean
|
|
|
|
// array.
|
|
|
|
using EdgeKind = typename EdgeType::EdgeKind;
|
|
|
|
EnumeratedArray<bool, EdgeKind> EdgeAlreadyCreated[DirectionCount]{false,
|
|
|
|
false};
|
|
|
|
|
|
|
|
auto createEdgeOfKind = [this](NodeType &Src, NodeType &Dst,
|
|
|
|
const EdgeKind K) {
|
|
|
|
switch (K) {
|
|
|
|
case EdgeKind::RegisterDefUse:
|
|
|
|
createDefUseEdge(Src, Dst);
|
|
|
|
break;
|
|
|
|
case EdgeKind::MemoryDependence:
|
|
|
|
createMemoryEdge(Src, Dst);
|
|
|
|
break;
|
|
|
|
case EdgeKind::Rooted:
|
|
|
|
createRootedEdge(Src, Dst);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
llvm_unreachable("Unsupported type of edge.");
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
auto reconnectEdges = [&](NodeType *Src, NodeType *Dst, NodeType *New,
|
|
|
|
const Direction Dir) {
|
|
|
|
if (!Src->hasEdgeTo(*Dst))
|
|
|
|
return;
|
|
|
|
LLVM_DEBUG(
|
|
|
|
dbgs() << "reconnecting("
|
|
|
|
<< (Dir == Direction::Incoming ? "incoming)" : "outgoing)")
|
|
|
|
<< ":\nSrc:" << *Src << "\nDst:" << *Dst << "\nNew:" << *New
|
|
|
|
<< "\n");
|
|
|
|
assert((Dir == Direction::Incoming || Dir == Direction::Outgoing) &&
|
|
|
|
"Invalid direction.");
|
|
|
|
|
|
|
|
SmallVector<EdgeType *, 10> EL;
|
|
|
|
Src->findEdgesTo(*Dst, EL);
|
|
|
|
for (EdgeType *OldEdge : EL) {
|
|
|
|
EdgeKind Kind = OldEdge->getKind();
|
|
|
|
if (!EdgeAlreadyCreated[Dir][Kind]) {
|
|
|
|
if (Dir == Direction::Incoming) {
|
|
|
|
createEdgeOfKind(*Src, *New, Kind);
|
|
|
|
LLVM_DEBUG(dbgs() << "created edge from Src to New.\n");
|
|
|
|
} else if (Dir == Direction::Outgoing) {
|
|
|
|
createEdgeOfKind(*New, *Dst, Kind);
|
|
|
|
LLVM_DEBUG(dbgs() << "created edge from New to Dst.\n");
|
[DDG] Data Dependence Graph - Pi Block
Summary:
This patch adds Pi Blocks to the DDG. A pi-block represents a group of DDG
nodes that are part of a strongly-connected component of the graph.
Replacing all the SCCs with pi-blocks results in an acyclic representation
of the DDG. For example if we have:
{a -> b}, {b -> c, d}, {c -> a}
the cycle a -> b -> c -> a is abstracted into a pi-block "p" as follows:
{p -> d} with "p" containing: {a -> b}, {b -> c}, {c -> a}
In this implementation the edges between nodes that are part of the pi-block
are preserved. The crossing edges (edges where one end of the edge is in the
set of nodes belonging to an SCC and the other end is outside that set) are
replaced with corresponding edges to/from the pi-block node instead.
Authored By: bmahjour
Reviewer: Meinersbur, fhahn, myhsu, xtian, dmgreen, kbarton, jdoerfert
Reviewed By: Meinersbur
Subscribers: ychen, arphaman, simoll, a.elovikov, mgorny, hiraditya, jfb, wuzish, llvm-commits, jsji, Whitney, etiotto, ppc-slack
Tag: #llvm
Differential Revision: https://reviews.llvm.org/D68827
2019-11-08 21:05:06 +01:00
|
|
|
}
|
2021-01-07 16:31:11 +01:00
|
|
|
EdgeAlreadyCreated[Dir][Kind] = true;
|
[DDG] Data Dependence Graph - Pi Block
Summary:
This patch adds Pi Blocks to the DDG. A pi-block represents a group of DDG
nodes that are part of a strongly-connected component of the graph.
Replacing all the SCCs with pi-blocks results in an acyclic representation
of the DDG. For example if we have:
{a -> b}, {b -> c, d}, {c -> a}
the cycle a -> b -> c -> a is abstracted into a pi-block "p" as follows:
{p -> d} with "p" containing: {a -> b}, {b -> c}, {c -> a}
In this implementation the edges between nodes that are part of the pi-block
are preserved. The crossing edges (edges where one end of the edge is in the
set of nodes belonging to an SCC and the other end is outside that set) are
replaced with corresponding edges to/from the pi-block node instead.
Authored By: bmahjour
Reviewer: Meinersbur, fhahn, myhsu, xtian, dmgreen, kbarton, jdoerfert
Reviewed By: Meinersbur
Subscribers: ychen, arphaman, simoll, a.elovikov, mgorny, hiraditya, jfb, wuzish, llvm-commits, jsji, Whitney, etiotto, ppc-slack
Tag: #llvm
Differential Revision: https://reviews.llvm.org/D68827
2019-11-08 21:05:06 +01:00
|
|
|
}
|
2021-01-07 16:31:11 +01:00
|
|
|
Src->removeEdge(*OldEdge);
|
|
|
|
destroyEdge(*OldEdge);
|
|
|
|
LLVM_DEBUG(dbgs() << "removed old edge between Src and Dst.\n\n");
|
|
|
|
}
|
|
|
|
};
|
[DDG] Data Dependence Graph - Pi Block
Summary:
This patch adds Pi Blocks to the DDG. A pi-block represents a group of DDG
nodes that are part of a strongly-connected component of the graph.
Replacing all the SCCs with pi-blocks results in an acyclic representation
of the DDG. For example if we have:
{a -> b}, {b -> c, d}, {c -> a}
the cycle a -> b -> c -> a is abstracted into a pi-block "p" as follows:
{p -> d} with "p" containing: {a -> b}, {b -> c}, {c -> a}
In this implementation the edges between nodes that are part of the pi-block
are preserved. The crossing edges (edges where one end of the edge is in the
set of nodes belonging to an SCC and the other end is outside that set) are
replaced with corresponding edges to/from the pi-block node instead.
Authored By: bmahjour
Reviewer: Meinersbur, fhahn, myhsu, xtian, dmgreen, kbarton, jdoerfert
Reviewed By: Meinersbur
Subscribers: ychen, arphaman, simoll, a.elovikov, mgorny, hiraditya, jfb, wuzish, llvm-commits, jsji, Whitney, etiotto, ppc-slack
Tag: #llvm
Differential Revision: https://reviews.llvm.org/D68827
2019-11-08 21:05:06 +01:00
|
|
|
|
2021-01-07 16:31:11 +01:00
|
|
|
for (NodeType *SCCNode : NL) {
|
[DDG] Data Dependence Graph - Pi Block
Summary:
This patch adds Pi Blocks to the DDG. A pi-block represents a group of DDG
nodes that are part of a strongly-connected component of the graph.
Replacing all the SCCs with pi-blocks results in an acyclic representation
of the DDG. For example if we have:
{a -> b}, {b -> c, d}, {c -> a}
the cycle a -> b -> c -> a is abstracted into a pi-block "p" as follows:
{p -> d} with "p" containing: {a -> b}, {b -> c}, {c -> a}
In this implementation the edges between nodes that are part of the pi-block
are preserved. The crossing edges (edges where one end of the edge is in the
set of nodes belonging to an SCC and the other end is outside that set) are
replaced with corresponding edges to/from the pi-block node instead.
Authored By: bmahjour
Reviewer: Meinersbur, fhahn, myhsu, xtian, dmgreen, kbarton, jdoerfert
Reviewed By: Meinersbur
Subscribers: ychen, arphaman, simoll, a.elovikov, mgorny, hiraditya, jfb, wuzish, llvm-commits, jsji, Whitney, etiotto, ppc-slack
Tag: #llvm
Differential Revision: https://reviews.llvm.org/D68827
2019-11-08 21:05:06 +01:00
|
|
|
// Process incoming edges incident to the pi-block node.
|
|
|
|
reconnectEdges(N, SCCNode, &PiNode, Direction::Incoming);
|
|
|
|
|
|
|
|
// Process edges that are coming out of the pi-block node.
|
|
|
|
reconnectEdges(SCCNode, N, &PiNode, Direction::Outgoing);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
[DDG] Data Dependence Graph - Ordinals
Summary:
This patch associates ordinal numbers to the DDG Nodes allowing
the builder to order nodes within a pi-block in program order. The
algorithm works by simply assuming the order in which the BBList
is fed into the builder. The builder already relies on the blocks being
in program order so that it can compute the dependencies correctly.
Similarly the order of instructions in their parent basic blocks
determine their program order.
Authored By: bmahjour
Reviewer: Meinersbur, fhahn, myhsu, xtian, dmgreen, kbarton, jdoerfert
Reviewed By: Meinersbur
Subscribers: ychen, arphaman, simoll, a.elovikov, mgorny, hiraditya, jfb, wuzish, llvm-commits, jsji, Whitney, etiotto, ppc-slack
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70986
2019-12-19 16:56:44 +01:00
|
|
|
// Ordinal maps are no longer needed.
|
|
|
|
InstOrdinalMap.clear();
|
|
|
|
NodeOrdinalMap.clear();
|
|
|
|
|
[DDG] Data Dependence Graph - Pi Block
Summary:
This patch adds Pi Blocks to the DDG. A pi-block represents a group of DDG
nodes that are part of a strongly-connected component of the graph.
Replacing all the SCCs with pi-blocks results in an acyclic representation
of the DDG. For example if we have:
{a -> b}, {b -> c, d}, {c -> a}
the cycle a -> b -> c -> a is abstracted into a pi-block "p" as follows:
{p -> d} with "p" containing: {a -> b}, {b -> c}, {c -> a}
In this implementation the edges between nodes that are part of the pi-block
are preserved. The crossing edges (edges where one end of the edge is in the
set of nodes belonging to an SCC and the other end is outside that set) are
replaced with corresponding edges to/from the pi-block node instead.
Authored By: bmahjour
Reviewer: Meinersbur, fhahn, myhsu, xtian, dmgreen, kbarton, jdoerfert
Reviewed By: Meinersbur
Subscribers: ychen, arphaman, simoll, a.elovikov, mgorny, hiraditya, jfb, wuzish, llvm-commits, jsji, Whitney, etiotto, ppc-slack
Tag: #llvm
Differential Revision: https://reviews.llvm.org/D68827
2019-11-08 21:05:06 +01:00
|
|
|
LLVM_DEBUG(dbgs() << "==== End of Creation of Pi-Blocks ===\n");
|
|
|
|
}
|
|
|
|
|
Data Dependence Graph Basics
Summary:
This is the first patch in a series of patches that will implement data dependence graph in LLVM. Many of the ideas used in this implementation are based on the following paper:
D. J. Kuck, R. H. Kuhn, D. A. Padua, B. Leasure, and M. Wolfe (1981). DEPENDENCE GRAPHS AND COMPILER OPTIMIZATIONS.
This patch contains support for a basic DDGs containing only atomic nodes (one node for each instruction). The edges are two fold: def-use edges and memory-dependence edges.
The implementation takes a list of basic-blocks and only considers dependencies among instructions in those basic blocks. Any dependencies coming into or going out of instructions that do not belong to those basic blocks are ignored.
The algorithm for building the graph involves the following steps in order:
1. For each instruction in the range of basic blocks to consider, create an atomic node in the resulting graph.
2. For each node in the graph establish def-use edges to/from other nodes in the graph.
3. For each pair of nodes containing memory instruction(s) create memory edges between them. This part of the algorithm goes through the instructions in lexicographical order and creates edges in reverse order if the sink of the dependence occurs before the source of it.
Authored By: bmahjour
Reviewer: Meinersbur, fhahn, myhsu, xtian, dmgreen, kbarton, jdoerfert
Reviewed By: Meinersbur, fhahn, myhsu
Subscribers: ychen, arphaman, simoll, a.elovikov, mgorny, hiraditya, jfb, wuzish, llvm-commits, jsji, Whitney, etiotto
Tag: #llvm
Differential Revision: https://reviews.llvm.org/D65350
llvm-svn: 372238
2019-09-18 19:43:45 +02:00
|
|
|
template <class G> void AbstractDependenceGraphBuilder<G>::createDefUseEdges() {
|
|
|
|
for (NodeType *N : Graph) {
|
|
|
|
InstructionListType SrcIList;
|
|
|
|
N->collectInstructions([](const Instruction *I) { return true; }, SrcIList);
|
|
|
|
|
|
|
|
// Use a set to mark the targets that we link to N, so we don't add
|
|
|
|
// duplicate def-use edges when more than one instruction in a target node
|
|
|
|
// use results of instructions that are contained in N.
|
|
|
|
SmallPtrSet<NodeType *, 4> VisitedTargets;
|
|
|
|
|
|
|
|
for (Instruction *II : SrcIList) {
|
|
|
|
for (User *U : II->users()) {
|
|
|
|
Instruction *UI = dyn_cast<Instruction>(U);
|
|
|
|
if (!UI)
|
|
|
|
continue;
|
|
|
|
NodeType *DstNode = nullptr;
|
|
|
|
if (IMap.find(UI) != IMap.end())
|
|
|
|
DstNode = IMap.find(UI)->second;
|
|
|
|
|
|
|
|
// In the case of loops, the scope of the subgraph is all the
|
|
|
|
// basic blocks (and instructions within them) belonging to the loop. We
|
|
|
|
// simply ignore all the edges coming from (or going into) instructions
|
|
|
|
// or basic blocks outside of this range.
|
|
|
|
if (!DstNode) {
|
|
|
|
LLVM_DEBUG(
|
|
|
|
dbgs()
|
|
|
|
<< "skipped def-use edge since the sink" << *UI
|
|
|
|
<< " is outside the range of instructions being considered.\n");
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Self dependencies are ignored because they are redundant and
|
|
|
|
// uninteresting.
|
|
|
|
if (DstNode == N) {
|
|
|
|
LLVM_DEBUG(dbgs()
|
|
|
|
<< "skipped def-use edge since the sink and the source ("
|
|
|
|
<< N << ") are the same.\n");
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (VisitedTargets.insert(DstNode).second) {
|
|
|
|
createDefUseEdge(*N, *DstNode);
|
|
|
|
++TotalDefUseEdges;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
template <class G>
|
|
|
|
void AbstractDependenceGraphBuilder<G>::createMemoryDependencyEdges() {
|
|
|
|
using DGIterator = typename G::iterator;
|
|
|
|
auto isMemoryAccess = [](const Instruction *I) {
|
|
|
|
return I->mayReadOrWriteMemory();
|
|
|
|
};
|
|
|
|
for (DGIterator SrcIt = Graph.begin(), E = Graph.end(); SrcIt != E; ++SrcIt) {
|
|
|
|
InstructionListType SrcIList;
|
|
|
|
(*SrcIt)->collectInstructions(isMemoryAccess, SrcIList);
|
|
|
|
if (SrcIList.empty())
|
|
|
|
continue;
|
|
|
|
|
|
|
|
for (DGIterator DstIt = SrcIt; DstIt != E; ++DstIt) {
|
|
|
|
if (**SrcIt == **DstIt)
|
|
|
|
continue;
|
|
|
|
InstructionListType DstIList;
|
|
|
|
(*DstIt)->collectInstructions(isMemoryAccess, DstIList);
|
|
|
|
if (DstIList.empty())
|
|
|
|
continue;
|
|
|
|
bool ForwardEdgeCreated = false;
|
|
|
|
bool BackwardEdgeCreated = false;
|
|
|
|
for (Instruction *ISrc : SrcIList) {
|
|
|
|
for (Instruction *IDst : DstIList) {
|
|
|
|
auto D = DI.depends(ISrc, IDst, true);
|
|
|
|
if (!D)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// If we have a dependence with its left-most non-'=' direction
|
|
|
|
// being '>' we need to reverse the direction of the edge, because
|
|
|
|
// the source of the dependence cannot occur after the sink. For
|
|
|
|
// confused dependencies, we will create edges in both directions to
|
|
|
|
// represent the possibility of a cycle.
|
|
|
|
|
|
|
|
auto createConfusedEdges = [&](NodeType &Src, NodeType &Dst) {
|
|
|
|
if (!ForwardEdgeCreated) {
|
|
|
|
createMemoryEdge(Src, Dst);
|
|
|
|
++TotalMemoryEdges;
|
|
|
|
}
|
|
|
|
if (!BackwardEdgeCreated) {
|
|
|
|
createMemoryEdge(Dst, Src);
|
|
|
|
++TotalMemoryEdges;
|
|
|
|
}
|
|
|
|
ForwardEdgeCreated = BackwardEdgeCreated = true;
|
|
|
|
++TotalConfusedEdges;
|
|
|
|
};
|
|
|
|
|
|
|
|
auto createForwardEdge = [&](NodeType &Src, NodeType &Dst) {
|
|
|
|
if (!ForwardEdgeCreated) {
|
|
|
|
createMemoryEdge(Src, Dst);
|
|
|
|
++TotalMemoryEdges;
|
|
|
|
}
|
|
|
|
ForwardEdgeCreated = true;
|
|
|
|
};
|
|
|
|
|
|
|
|
auto createBackwardEdge = [&](NodeType &Src, NodeType &Dst) {
|
|
|
|
if (!BackwardEdgeCreated) {
|
|
|
|
createMemoryEdge(Dst, Src);
|
|
|
|
++TotalMemoryEdges;
|
|
|
|
}
|
|
|
|
BackwardEdgeCreated = true;
|
|
|
|
};
|
|
|
|
|
|
|
|
if (D->isConfused())
|
|
|
|
createConfusedEdges(**SrcIt, **DstIt);
|
|
|
|
else if (D->isOrdered() && !D->isLoopIndependent()) {
|
|
|
|
bool ReversedEdge = false;
|
|
|
|
for (unsigned Level = 1; Level <= D->getLevels(); ++Level) {
|
|
|
|
if (D->getDirection(Level) == Dependence::DVEntry::EQ)
|
|
|
|
continue;
|
|
|
|
else if (D->getDirection(Level) == Dependence::DVEntry::GT) {
|
|
|
|
createBackwardEdge(**SrcIt, **DstIt);
|
|
|
|
ReversedEdge = true;
|
|
|
|
++TotalEdgeReversals;
|
|
|
|
break;
|
|
|
|
} else if (D->getDirection(Level) == Dependence::DVEntry::LT)
|
|
|
|
break;
|
|
|
|
else {
|
|
|
|
createConfusedEdges(**SrcIt, **DstIt);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (!ReversedEdge)
|
|
|
|
createForwardEdge(**SrcIt, **DstIt);
|
|
|
|
} else
|
|
|
|
createForwardEdge(**SrcIt, **DstIt);
|
|
|
|
|
|
|
|
// Avoid creating duplicate edges.
|
|
|
|
if (ForwardEdgeCreated && BackwardEdgeCreated)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If we've created edges in both directions, there is no more
|
|
|
|
// unique edge that we can create between these two nodes, so we
|
|
|
|
// can exit early.
|
|
|
|
if (ForwardEdgeCreated && BackwardEdgeCreated)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
[DDG] Data Dependence Graph - Graph Simplification
Summary:
This is the last functional patch affecting the representation of DDG.
Here we try to simplify the DDG to reduce the number of nodes and edges by
iteratively merging pairs of nodes that satisfy the following conditions,
until no such pair can be identified. A pair of nodes consisting of a and b
can be merged if:
1. the only edge from a is a def-use edge to b and
2. the only edge to b is a def-use edge from a and
3. there is no cyclic edge from b to a and
4. all instructions in a and b belong to the same basic block and
5. both a and b are simple (single or multi instruction) nodes.
These criteria allow us to fold many uninteresting def-use edges that
commonly exist in the graph while avoiding the risk of introducing
dependencies that didn't exist before.
Authored By: bmahjour
Reviewer: Meinersbur, fhahn, myhsu, xtian, dmgreen, kbarton, jdoerfert
Reviewed By: Meinersbur
Subscribers: ychen, arphaman, simoll, a.elovikov, mgorny, hiraditya, jfb, wuzish, llvm-commits, jsji, Whitney, etiotto, ppc-slack
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D72350
2020-02-18 22:38:10 +01:00
|
|
|
template <class G> void AbstractDependenceGraphBuilder<G>::simplify() {
|
|
|
|
if (!shouldSimplify())
|
|
|
|
return;
|
|
|
|
LLVM_DEBUG(dbgs() << "==== Start of Graph Simplification ===\n");
|
|
|
|
|
|
|
|
// This algorithm works by first collecting a set of candidate nodes that have
|
|
|
|
// an out-degree of one (in terms of def-use edges), and then ignoring those
|
|
|
|
// whose targets have an in-degree more than one. Each node in the resulting
|
|
|
|
// set can then be merged with its corresponding target and put back into the
|
|
|
|
// worklist until no further merge candidates are available.
|
|
|
|
SmallPtrSet<NodeType *, 32> CandidateSourceNodes;
|
|
|
|
|
|
|
|
// A mapping between nodes and their in-degree. To save space, this map
|
|
|
|
// only contains nodes that are targets of nodes in the CandidateSourceNodes.
|
|
|
|
DenseMap<NodeType *, unsigned> TargetInDegreeMap;
|
|
|
|
|
|
|
|
for (NodeType *N : Graph) {
|
|
|
|
if (N->getEdges().size() != 1)
|
|
|
|
continue;
|
|
|
|
EdgeType &Edge = N->back();
|
|
|
|
if (!Edge.isDefUse())
|
|
|
|
continue;
|
|
|
|
CandidateSourceNodes.insert(N);
|
|
|
|
|
|
|
|
// Insert an element into the in-degree map and initialize to zero. The
|
|
|
|
// count will get updated in the next step.
|
|
|
|
TargetInDegreeMap.insert({&Edge.getTargetNode(), 0});
|
|
|
|
}
|
|
|
|
|
|
|
|
LLVM_DEBUG({
|
|
|
|
dbgs() << "Size of candidate src node list:" << CandidateSourceNodes.size()
|
|
|
|
<< "\nNode with single outgoing def-use edge:\n";
|
|
|
|
for (NodeType *N : CandidateSourceNodes) {
|
|
|
|
dbgs() << N << "\n";
|
|
|
|
}
|
|
|
|
});
|
|
|
|
|
|
|
|
for (NodeType *N : Graph) {
|
|
|
|
for (EdgeType *E : *N) {
|
|
|
|
NodeType *Tgt = &E->getTargetNode();
|
|
|
|
auto TgtIT = TargetInDegreeMap.find(Tgt);
|
|
|
|
if (TgtIT != TargetInDegreeMap.end())
|
|
|
|
++(TgtIT->second);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
LLVM_DEBUG({
|
|
|
|
dbgs() << "Size of target in-degree map:" << TargetInDegreeMap.size()
|
|
|
|
<< "\nContent of in-degree map:\n";
|
|
|
|
for (auto &I : TargetInDegreeMap) {
|
|
|
|
dbgs() << I.first << " --> " << I.second << "\n";
|
|
|
|
}
|
|
|
|
});
|
|
|
|
|
|
|
|
SmallVector<NodeType *, 32> Worklist(CandidateSourceNodes.begin(),
|
|
|
|
CandidateSourceNodes.end());
|
|
|
|
while (!Worklist.empty()) {
|
|
|
|
NodeType &Src = *Worklist.pop_back_val();
|
|
|
|
// As nodes get merged, we need to skip any node that has been removed from
|
|
|
|
// the candidate set (see below).
|
2020-06-07 22:36:10 +02:00
|
|
|
if (!CandidateSourceNodes.erase(&Src))
|
[DDG] Data Dependence Graph - Graph Simplification
Summary:
This is the last functional patch affecting the representation of DDG.
Here we try to simplify the DDG to reduce the number of nodes and edges by
iteratively merging pairs of nodes that satisfy the following conditions,
until no such pair can be identified. A pair of nodes consisting of a and b
can be merged if:
1. the only edge from a is a def-use edge to b and
2. the only edge to b is a def-use edge from a and
3. there is no cyclic edge from b to a and
4. all instructions in a and b belong to the same basic block and
5. both a and b are simple (single or multi instruction) nodes.
These criteria allow us to fold many uninteresting def-use edges that
commonly exist in the graph while avoiding the risk of introducing
dependencies that didn't exist before.
Authored By: bmahjour
Reviewer: Meinersbur, fhahn, myhsu, xtian, dmgreen, kbarton, jdoerfert
Reviewed By: Meinersbur
Subscribers: ychen, arphaman, simoll, a.elovikov, mgorny, hiraditya, jfb, wuzish, llvm-commits, jsji, Whitney, etiotto, ppc-slack
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D72350
2020-02-18 22:38:10 +01:00
|
|
|
continue;
|
|
|
|
|
|
|
|
assert(Src.getEdges().size() == 1 &&
|
|
|
|
"Expected a single edge from the candidate src node.");
|
|
|
|
NodeType &Tgt = Src.back().getTargetNode();
|
|
|
|
assert(TargetInDegreeMap.find(&Tgt) != TargetInDegreeMap.end() &&
|
|
|
|
"Expected target to be in the in-degree map.");
|
|
|
|
|
|
|
|
if (TargetInDegreeMap[&Tgt] != 1)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (!areNodesMergeable(Src, Tgt))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// Do not merge if there is also an edge from target to src (immediate
|
|
|
|
// cycle).
|
|
|
|
if (Tgt.hasEdgeTo(Src))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
LLVM_DEBUG(dbgs() << "Merging:" << Src << "\nWith:" << Tgt << "\n");
|
|
|
|
|
|
|
|
mergeNodes(Src, Tgt);
|
|
|
|
|
|
|
|
// If the target node is in the candidate set itself, we need to put the
|
|
|
|
// src node back into the worklist again so it gives the target a chance
|
|
|
|
// to get merged into it. For example if we have:
|
|
|
|
// {(a)->(b), (b)->(c), (c)->(d), ...} and the worklist is initially {b, a},
|
|
|
|
// then after merging (a) and (b) together, we need to put (a,b) back in
|
|
|
|
// the worklist so that (c) can get merged in as well resulting in
|
|
|
|
// {(a,b,c) -> d}
|
|
|
|
// We also need to remove the old target (b), from the worklist. We first
|
|
|
|
// remove it from the candidate set here, and skip any item from the
|
|
|
|
// worklist that is not in the set.
|
2020-06-07 22:36:10 +02:00
|
|
|
if (CandidateSourceNodes.erase(&Tgt)) {
|
[DDG] Data Dependence Graph - Graph Simplification
Summary:
This is the last functional patch affecting the representation of DDG.
Here we try to simplify the DDG to reduce the number of nodes and edges by
iteratively merging pairs of nodes that satisfy the following conditions,
until no such pair can be identified. A pair of nodes consisting of a and b
can be merged if:
1. the only edge from a is a def-use edge to b and
2. the only edge to b is a def-use edge from a and
3. there is no cyclic edge from b to a and
4. all instructions in a and b belong to the same basic block and
5. both a and b are simple (single or multi instruction) nodes.
These criteria allow us to fold many uninteresting def-use edges that
commonly exist in the graph while avoiding the risk of introducing
dependencies that didn't exist before.
Authored By: bmahjour
Reviewer: Meinersbur, fhahn, myhsu, xtian, dmgreen, kbarton, jdoerfert
Reviewed By: Meinersbur
Subscribers: ychen, arphaman, simoll, a.elovikov, mgorny, hiraditya, jfb, wuzish, llvm-commits, jsji, Whitney, etiotto, ppc-slack
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D72350
2020-02-18 22:38:10 +01:00
|
|
|
Worklist.push_back(&Src);
|
|
|
|
CandidateSourceNodes.insert(&Src);
|
|
|
|
LLVM_DEBUG(dbgs() << "Putting " << &Src << " back in the worklist.\n");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
LLVM_DEBUG(dbgs() << "=== End of Graph Simplification ===\n");
|
|
|
|
}
|
|
|
|
|
[DDG] Data Dependence Graph - Topological Sort (Memory Leak Fix)
Summary:
This fixes the memory leak in bec37c3fc766a7b97f8c52c181c325fd47b75259
and re-delivers the reverted patch.
In this patch the DDG DAG is sorted topologically to put the
nodes in the graph in the order that would satisfy all
dependencies. This helps transformations that would like to
generate code based on the DDG. Since the DDG is a DAG a
reverse-post-order traversal would give us the topological
ordering. This patch also sorts the basic blocks passed to
the builder based on program order to ensure that the
dependencies are computed in the correct direction.
Authored By: bmahjour
Reviewer: Meinersbur, fhahn, myhsu, xtian, dmgreen, kbarton, jdoerfert
Reviewed By: Meinersbur
Subscribers: ychen, arphaman, simoll, a.elovikov, mgorny, hiraditya, jfb, wuzish, llvm-commits, jsji, Whitney, etiotto, ppc-slack
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70609
2019-12-02 21:23:26 +01:00
|
|
|
template <class G>
|
|
|
|
void AbstractDependenceGraphBuilder<G>::sortNodesTopologically() {
|
|
|
|
|
|
|
|
// If we don't create pi-blocks, then we may not have a DAG.
|
|
|
|
if (!shouldCreatePiBlocks())
|
|
|
|
return;
|
|
|
|
|
|
|
|
SmallVector<NodeType *, 64> NodesInPO;
|
|
|
|
using NodeKind = typename NodeType::NodeKind;
|
|
|
|
for (NodeType *N : post_order(&Graph)) {
|
|
|
|
if (N->getKind() == NodeKind::PiBlock) {
|
|
|
|
// Put members of the pi-block right after the pi-block itself, for
|
|
|
|
// convenience.
|
|
|
|
const NodeListType &PiBlockMembers = getNodesInPiBlock(*N);
|
2020-12-30 04:23:21 +01:00
|
|
|
llvm::append_range(NodesInPO, PiBlockMembers);
|
[DDG] Data Dependence Graph - Topological Sort (Memory Leak Fix)
Summary:
This fixes the memory leak in bec37c3fc766a7b97f8c52c181c325fd47b75259
and re-delivers the reverted patch.
In this patch the DDG DAG is sorted topologically to put the
nodes in the graph in the order that would satisfy all
dependencies. This helps transformations that would like to
generate code based on the DDG. Since the DDG is a DAG a
reverse-post-order traversal would give us the topological
ordering. This patch also sorts the basic blocks passed to
the builder based on program order to ensure that the
dependencies are computed in the correct direction.
Authored By: bmahjour
Reviewer: Meinersbur, fhahn, myhsu, xtian, dmgreen, kbarton, jdoerfert
Reviewed By: Meinersbur
Subscribers: ychen, arphaman, simoll, a.elovikov, mgorny, hiraditya, jfb, wuzish, llvm-commits, jsji, Whitney, etiotto, ppc-slack
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70609
2019-12-02 21:23:26 +01:00
|
|
|
}
|
|
|
|
NodesInPO.push_back(N);
|
|
|
|
}
|
|
|
|
|
|
|
|
size_t OldSize = Graph.Nodes.size();
|
|
|
|
Graph.Nodes.clear();
|
2021-01-23 08:25:01 +01:00
|
|
|
append_range(Graph.Nodes, reverse(NodesInPO));
|
[DDG] Data Dependence Graph - Topological Sort (Memory Leak Fix)
Summary:
This fixes the memory leak in bec37c3fc766a7b97f8c52c181c325fd47b75259
and re-delivers the reverted patch.
In this patch the DDG DAG is sorted topologically to put the
nodes in the graph in the order that would satisfy all
dependencies. This helps transformations that would like to
generate code based on the DDG. Since the DDG is a DAG a
reverse-post-order traversal would give us the topological
ordering. This patch also sorts the basic blocks passed to
the builder based on program order to ensure that the
dependencies are computed in the correct direction.
Authored By: bmahjour
Reviewer: Meinersbur, fhahn, myhsu, xtian, dmgreen, kbarton, jdoerfert
Reviewed By: Meinersbur
Subscribers: ychen, arphaman, simoll, a.elovikov, mgorny, hiraditya, jfb, wuzish, llvm-commits, jsji, Whitney, etiotto, ppc-slack
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D70609
2019-12-02 21:23:26 +01:00
|
|
|
if (Graph.Nodes.size() != OldSize)
|
|
|
|
assert(false &&
|
|
|
|
"Expected the number of nodes to stay the same after the sort");
|
|
|
|
}
|
|
|
|
|
Data Dependence Graph Basics
Summary:
This is the first patch in a series of patches that will implement data dependence graph in LLVM. Many of the ideas used in this implementation are based on the following paper:
D. J. Kuck, R. H. Kuhn, D. A. Padua, B. Leasure, and M. Wolfe (1981). DEPENDENCE GRAPHS AND COMPILER OPTIMIZATIONS.
This patch contains support for a basic DDGs containing only atomic nodes (one node for each instruction). The edges are two fold: def-use edges and memory-dependence edges.
The implementation takes a list of basic-blocks and only considers dependencies among instructions in those basic blocks. Any dependencies coming into or going out of instructions that do not belong to those basic blocks are ignored.
The algorithm for building the graph involves the following steps in order:
1. For each instruction in the range of basic blocks to consider, create an atomic node in the resulting graph.
2. For each node in the graph establish def-use edges to/from other nodes in the graph.
3. For each pair of nodes containing memory instruction(s) create memory edges between them. This part of the algorithm goes through the instructions in lexicographical order and creates edges in reverse order if the sink of the dependence occurs before the source of it.
Authored By: bmahjour
Reviewer: Meinersbur, fhahn, myhsu, xtian, dmgreen, kbarton, jdoerfert
Reviewed By: Meinersbur, fhahn, myhsu
Subscribers: ychen, arphaman, simoll, a.elovikov, mgorny, hiraditya, jfb, wuzish, llvm-commits, jsji, Whitney, etiotto
Tag: #llvm
Differential Revision: https://reviews.llvm.org/D65350
llvm-svn: 372238
2019-09-18 19:43:45 +02:00
|
|
|
template class llvm::AbstractDependenceGraphBuilder<DataDependenceGraph>;
|
|
|
|
template class llvm::DependenceGraphInfo<DDGNode>;
|