2008-11-02 13:52:50 +08:00
|
|
|
//===- MergeFunctions.cpp - Merge identical functions ---------------------===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This pass looks for equivalent functions that are mergable and folds them.
|
|
|
|
//
|
2014-06-22 08:57:09 +08:00
|
|
|
// Order relation is defined on set of functions. It was made through
|
|
|
|
// special function comparison procedure that returns
|
|
|
|
// 0 when functions are equal,
|
|
|
|
// -1 when Left function is less than right function, and
|
|
|
|
// 1 for opposite case. We need total-ordering, so we need to maintain
|
|
|
|
// four properties on the functions set:
|
|
|
|
// a <= a (reflexivity)
|
|
|
|
// if a <= b and b <= a then a = b (antisymmetry)
|
|
|
|
// if a <= b and b <= c then a <= c (transitivity).
|
|
|
|
// for all a and b: a <= b or b <= a (totality).
|
2008-11-02 13:52:50 +08:00
|
|
|
//
|
2014-06-22 08:57:09 +08:00
|
|
|
// Comparison iterates through each instruction in each basic block.
|
|
|
|
// Functions are kept on binary tree. For each new function F we perform
|
|
|
|
// lookup in binary tree.
|
|
|
|
// In practice it works the following way:
|
|
|
|
// -- We define Function* container class with custom "operator<" (FunctionPtr).
|
|
|
|
// -- "FunctionPtr" instances are stored in std::set collection, so every
|
|
|
|
// std::set::insert operation will give you result in log(N) time.
|
Accelerate MergeFunctions with hashing
This patch makes the Merge Functions pass faster by calculating and comparing
a hash value which captures the essential structure of a function before
performing a full function comparison.
The hash is calculated by hashing the function signature, then walking the basic
blocks of the function in the same order as the main comparison function. The
opcode of each instruction is hashed in sequence, which means that different
functions according to the existing total order cannot have the same hash, as
the comparison requires the opcodes of the two functions to be the same order.
The hash function is a static member of the FunctionComparator class because it
is tightly coupled to the exact comparison function used. For example, functions
which are equivalent modulo a single variant callsite might be merged by a more
aggressive MergeFunctions, and the hash function would need to be insensitive to
these differences in order to exploit this.
The hashing function uses a utility class which accumulates the values into an
internal state using a standard bit-mixing function. Note that this is a different interface
than a regular hashing routine, because the values to be hashed are scattered
amongst the properties of a llvm::Function, not linear in memory. This scheme is
fast because only one word of state needs to be kept, and the mixing function is
a few instructions.
The main runOnModule function first computes the hash of each function, and only
further processes functions which do not have a unique function hash. The hash
is also used to order the sorted function set. If the hashes differ, their
values are used to order the functions, otherwise the full comparison is done.
Both of these are helpful in speeding up MergeFunctions. Together they result in
speedups of 9% for mysqld (a mostly C application with little redundancy), 46%
for libxul in Firefox, and 117% for Chromium. (These are all LTO builds.) In all
three cases, the new speed of MergeFunctions is about half that of the module
verifier, making it relatively inexpensive even for large LTO builds with
hundreds of thousands of functions. The same functions are merged, so this
change is free performance.
Author: jrkoenig
Reviewers: nlewycky, dschuff, jfb
Subscribers: llvm-commits, aemerson
Differential revision: http://reviews.llvm.org/D11923
llvm-svn: 245140
2015-08-15 09:18:18 +08:00
|
|
|
//
|
|
|
|
// As an optimization, a hash of the function structure is calculated first, and
|
|
|
|
// two functions are only compared if they have the same hash. This hash is
|
|
|
|
// cheap to compute, and has the property that if function F == G according to
|
|
|
|
// the comparison function, then hash(F) == hash(G). This consistency property
|
|
|
|
// is critical to ensuring all possible merging opportunities are exploited.
|
|
|
|
// Collisions in the hash affect the speed of the pass but not the correctness
|
|
|
|
// or determinism of the resulting transformation.
|
2008-11-02 13:52:50 +08:00
|
|
|
//
|
2010-05-13 13:48:45 +08:00
|
|
|
// When a match is found the functions are folded. If both functions are
|
|
|
|
// overridable, we move the functionality into a new internal function and
|
|
|
|
// leave two overridable thunks to it.
|
2008-11-02 13:52:50 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// Future work:
|
|
|
|
//
|
|
|
|
// * virtual functions.
|
|
|
|
//
|
|
|
|
// Many functions have their address taken by the virtual function table for
|
|
|
|
// the object they belong to. However, as long as it's only used for a lookup
|
2010-08-08 13:04:23 +08:00
|
|
|
// and call, this is irrelevant, and we'd like to fold such functions.
|
2008-11-02 13:52:50 +08:00
|
|
|
//
|
2010-08-08 13:04:23 +08:00
|
|
|
// * be smarter about bitcasts.
|
2010-05-13 13:48:45 +08:00
|
|
|
//
|
|
|
|
// In order to fold functions, we will sometimes add either bitcast instructions
|
|
|
|
// or bitcast constant expressions. Unfortunately, this can confound further
|
|
|
|
// analysis since the two functions differ where one has a bitcast and the
|
2010-08-08 13:04:23 +08:00
|
|
|
// other doesn't. We should learn to look through bitcasts.
|
2010-05-13 13:48:45 +08:00
|
|
|
//
|
2014-06-22 08:57:09 +08:00
|
|
|
// * Compare complex types with pointer types inside.
|
|
|
|
// * Compare cross-reference cases.
|
|
|
|
// * Compare complex expressions.
|
|
|
|
//
|
|
|
|
// All the three issues above could be described as ability to prove that
|
|
|
|
// fA == fB == fC == fE == fF == fG in example below:
|
|
|
|
//
|
|
|
|
// void fA() {
|
|
|
|
// fB();
|
|
|
|
// }
|
|
|
|
// void fB() {
|
|
|
|
// fA();
|
|
|
|
// }
|
|
|
|
//
|
|
|
|
// void fE() {
|
|
|
|
// fF();
|
|
|
|
// }
|
|
|
|
// void fF() {
|
|
|
|
// fG();
|
|
|
|
// }
|
|
|
|
// void fG() {
|
|
|
|
// fE();
|
|
|
|
// }
|
|
|
|
//
|
|
|
|
// Simplest cross-reference case (fA <--> fB) was implemented in previous
|
|
|
|
// versions of MergeFunctions, though it presented only in two function pairs
|
|
|
|
// in test-suite (that counts >50k functions)
|
|
|
|
// Though possibility to detect complex cross-referencing (e.g.: A->B->C->D->A)
|
|
|
|
// could cover much more cases.
|
|
|
|
//
|
2008-11-02 13:52:50 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2017-10-20 05:21:30 +08:00
|
|
|
#include "llvm/ADT/ArrayRef.h"
|
2012-12-04 00:50:05 +08:00
|
|
|
#include "llvm/ADT/SmallSet.h"
|
2017-10-20 05:21:30 +08:00
|
|
|
#include "llvm/ADT/SmallVector.h"
|
2012-12-04 00:50:05 +08:00
|
|
|
#include "llvm/ADT/Statistic.h"
|
2017-10-20 05:21:30 +08:00
|
|
|
#include "llvm/IR/Argument.h"
|
|
|
|
#include "llvm/IR/Attributes.h"
|
|
|
|
#include "llvm/IR/BasicBlock.h"
|
2014-03-04 19:01:28 +08:00
|
|
|
#include "llvm/IR/CallSite.h"
|
2017-10-20 05:21:30 +08:00
|
|
|
#include "llvm/IR/Constant.h"
|
2013-01-02 19:36:10 +08:00
|
|
|
#include "llvm/IR/Constants.h"
|
2017-10-20 05:21:30 +08:00
|
|
|
#include "llvm/IR/DebugInfoMetadata.h"
|
|
|
|
#include "llvm/IR/DebugLoc.h"
|
|
|
|
#include "llvm/IR/DerivedTypes.h"
|
|
|
|
#include "llvm/IR/Function.h"
|
|
|
|
#include "llvm/IR/GlobalValue.h"
|
2013-01-02 19:36:10 +08:00
|
|
|
#include "llvm/IR/IRBuilder.h"
|
2017-10-20 05:21:30 +08:00
|
|
|
#include "llvm/IR/InstrTypes.h"
|
|
|
|
#include "llvm/IR/Instruction.h"
|
2013-01-02 19:36:10 +08:00
|
|
|
#include "llvm/IR/Instructions.h"
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
#include "llvm/IR/IntrinsicInst.h"
|
2013-01-02 19:36:10 +08:00
|
|
|
#include "llvm/IR/Module.h"
|
2017-10-20 05:21:30 +08:00
|
|
|
#include "llvm/IR/Type.h"
|
|
|
|
#include "llvm/IR/Use.h"
|
|
|
|
#include "llvm/IR/User.h"
|
|
|
|
#include "llvm/IR/Value.h"
|
2014-03-04 19:17:44 +08:00
|
|
|
#include "llvm/IR/ValueHandle.h"
|
Improve the determinism of MergeFunctions
Summary:
Merge functions previously relied on unsigned comparisons of pointer values to
order functions. This caused observable non-determinism in the compiler for
large bitcode programs. Basically, opt -mergefuncs program.bc | md5sum produces
different hashes when run repeatedly on the same machine. Differing output was
observed on three large bitcodes, but it was less frequent on the smallest file.
It is possible that this only manifests on the large inputs, hence remaining
undetected until now.
This patch fixes this by removing (almost, see below) all places where
comparisons between pointers are used to order functions. Most of these changes
are local, but the comparison of global values requires assigning an identifier
to each local in the order it is visited. This is very similar to the way the
comparison function identifies Value*'s defined within a function. Because the
order of visiting the functions and their subparts is deterministic, the
identifiers assigned to the globals will be as well, and the order of functions
will be deterministic.
With these changes, there is no more observed non-determinism. There is also
only minor slowdowns (negligible to 4%) compared to the baseline, which is
likely a result of the fact that global comparisons involve hash lookups and not
just pointer comparisons.
The one caveat so far is that programs containing BlockAddress constants can
still be non-deterministic. It is not clear what the right solution is here. In
particular, even if the global numbers are used to order by function, we still
need a way to order the BasicBlock*'s. Unfortunately, we cannot just bail out
and fail to order the functions or consider them equal, because we require a
total order over functions. Note that programs with BlockAddress constants are
relatively rare, so the impact of leaving this in is minor as long as this pass
is opt-in.
Author: jrkoenig
Reviewers: nlewycky, jfb, dschuff
Subscribers: jevinskie, llvm-commits, chapuni
Differential revision: http://reviews.llvm.org/D12168
llvm-svn: 245762
2015-08-22 07:27:24 +08:00
|
|
|
#include "llvm/IR/ValueMap.h"
|
2008-11-02 13:52:50 +08:00
|
|
|
#include "llvm/Pass.h"
|
2017-10-20 05:21:30 +08:00
|
|
|
#include "llvm/Support/Casting.h"
|
2014-06-22 02:58:11 +08:00
|
|
|
#include "llvm/Support/CommandLine.h"
|
2008-11-02 13:52:50 +08:00
|
|
|
#include "llvm/Support/Debug.h"
|
2009-07-25 08:23:56 +08:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2016-04-18 17:17:29 +08:00
|
|
|
#include "llvm/Transforms/IPO.h"
|
2016-11-12 05:15:13 +08:00
|
|
|
#include "llvm/Transforms/Utils/FunctionComparator.h"
|
2017-10-20 05:21:30 +08:00
|
|
|
#include <algorithm>
|
|
|
|
#include <cassert>
|
|
|
|
#include <iterator>
|
|
|
|
#include <set>
|
|
|
|
#include <utility>
|
2010-08-31 16:29:37 +08:00
|
|
|
#include <vector>
|
2015-10-07 07:24:35 +08:00
|
|
|
|
2008-11-02 13:52:50 +08:00
|
|
|
using namespace llvm;
|
|
|
|
|
2014-04-22 10:55:47 +08:00
|
|
|
#define DEBUG_TYPE "mergefunc"
|
|
|
|
|
2008-11-02 13:52:50 +08:00
|
|
|
STATISTIC(NumFunctionsMerged, "Number of functions merged");
|
2010-09-07 09:42:10 +08:00
|
|
|
STATISTIC(NumThunksWritten, "Number of thunks generated");
|
|
|
|
STATISTIC(NumDoubleWeak, "Number of new functions created");
|
2008-11-02 13:52:50 +08:00
|
|
|
|
2014-06-22 02:58:11 +08:00
|
|
|
static cl::opt<unsigned> NumFunctionsForSanityCheck(
|
|
|
|
"mergefunc-sanity",
|
|
|
|
cl::desc("How many functions in module could be used for "
|
|
|
|
"MergeFunctions pass sanity check. "
|
|
|
|
"'0' disables this check. Works only with '-debug' key."),
|
|
|
|
cl::init(0), cl::Hidden);
|
|
|
|
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
// Under option -mergefunc-preserve-debug-info we:
|
|
|
|
// - Do not create a new function for a thunk.
|
|
|
|
// - Retain the debug info for a thunk's parameters (and associated
|
|
|
|
// instructions for the debug info) from the entry block.
|
|
|
|
// Note: -debug will display the algorithm at work.
|
|
|
|
// - Create debug-info for the call (to the shared implementation) made by
|
|
|
|
// a thunk and its return value.
|
|
|
|
// - Erase the rest of the function, retaining the (minimally sized) entry
|
|
|
|
// block to create a thunk.
|
|
|
|
// - Preserve a thunk's call site to point to the thunk even when both occur
|
|
|
|
// within the same translation unit, to aid debugability. Note that this
|
|
|
|
// behaviour differs from the underlying -mergefunc implementation which
|
|
|
|
// modifies the thunk's call site to point to the shared implementation
|
|
|
|
// when both occur within the same translation unit.
|
|
|
|
static cl::opt<bool>
|
|
|
|
MergeFunctionsPDI("mergefunc-preserve-debug-info", cl::Hidden,
|
|
|
|
cl::init(false),
|
|
|
|
cl::desc("Preserve debug info in thunk when mergefunc "
|
|
|
|
"transformations are made."));
|
|
|
|
|
2010-09-05 17:00:32 +08:00
|
|
|
namespace {
|
|
|
|
|
2014-09-10 18:08:25 +08:00
|
|
|
class FunctionNode {
|
2015-06-09 08:03:29 +08:00
|
|
|
mutable AssertingVH<Function> F;
|
Accelerate MergeFunctions with hashing
This patch makes the Merge Functions pass faster by calculating and comparing
a hash value which captures the essential structure of a function before
performing a full function comparison.
The hash is calculated by hashing the function signature, then walking the basic
blocks of the function in the same order as the main comparison function. The
opcode of each instruction is hashed in sequence, which means that different
functions according to the existing total order cannot have the same hash, as
the comparison requires the opcodes of the two functions to be the same order.
The hash function is a static member of the FunctionComparator class because it
is tightly coupled to the exact comparison function used. For example, functions
which are equivalent modulo a single variant callsite might be merged by a more
aggressive MergeFunctions, and the hash function would need to be insensitive to
these differences in order to exploit this.
The hashing function uses a utility class which accumulates the values into an
internal state using a standard bit-mixing function. Note that this is a different interface
than a regular hashing routine, because the values to be hashed are scattered
amongst the properties of a llvm::Function, not linear in memory. This scheme is
fast because only one word of state needs to be kept, and the mixing function is
a few instructions.
The main runOnModule function first computes the hash of each function, and only
further processes functions which do not have a unique function hash. The hash
is also used to order the sorted function set. If the hashes differ, their
values are used to order the functions, otherwise the full comparison is done.
Both of these are helpful in speeding up MergeFunctions. Together they result in
speedups of 9% for mysqld (a mostly C application with little redundancy), 46%
for libxul in Firefox, and 117% for Chromium. (These are all LTO builds.) In all
three cases, the new speed of MergeFunctions is about half that of the module
verifier, making it relatively inexpensive even for large LTO builds with
hundreds of thousands of functions. The same functions are merged, so this
change is free performance.
Author: jrkoenig
Reviewers: nlewycky, dschuff, jfb
Subscribers: llvm-commits, aemerson
Differential revision: http://reviews.llvm.org/D11923
llvm-svn: 245140
2015-08-15 09:18:18 +08:00
|
|
|
FunctionComparator::FunctionHash Hash;
|
2017-10-20 05:21:30 +08:00
|
|
|
|
2014-06-22 04:54:36 +08:00
|
|
|
public:
|
Accelerate MergeFunctions with hashing
This patch makes the Merge Functions pass faster by calculating and comparing
a hash value which captures the essential structure of a function before
performing a full function comparison.
The hash is calculated by hashing the function signature, then walking the basic
blocks of the function in the same order as the main comparison function. The
opcode of each instruction is hashed in sequence, which means that different
functions according to the existing total order cannot have the same hash, as
the comparison requires the opcodes of the two functions to be the same order.
The hash function is a static member of the FunctionComparator class because it
is tightly coupled to the exact comparison function used. For example, functions
which are equivalent modulo a single variant callsite might be merged by a more
aggressive MergeFunctions, and the hash function would need to be insensitive to
these differences in order to exploit this.
The hashing function uses a utility class which accumulates the values into an
internal state using a standard bit-mixing function. Note that this is a different interface
than a regular hashing routine, because the values to be hashed are scattered
amongst the properties of a llvm::Function, not linear in memory. This scheme is
fast because only one word of state needs to be kept, and the mixing function is
a few instructions.
The main runOnModule function first computes the hash of each function, and only
further processes functions which do not have a unique function hash. The hash
is also used to order the sorted function set. If the hashes differ, their
values are used to order the functions, otherwise the full comparison is done.
Both of these are helpful in speeding up MergeFunctions. Together they result in
speedups of 9% for mysqld (a mostly C application with little redundancy), 46%
for libxul in Firefox, and 117% for Chromium. (These are all LTO builds.) In all
three cases, the new speed of MergeFunctions is about half that of the module
verifier, making it relatively inexpensive even for large LTO builds with
hundreds of thousands of functions. The same functions are merged, so this
change is free performance.
Author: jrkoenig
Reviewers: nlewycky, dschuff, jfb
Subscribers: llvm-commits, aemerson
Differential revision: http://reviews.llvm.org/D11923
llvm-svn: 245140
2015-08-15 09:18:18 +08:00
|
|
|
// Note the hash is recalculated potentially multiple times, but it is cheap.
|
Improve the determinism of MergeFunctions
Summary:
Merge functions previously relied on unsigned comparisons of pointer values to
order functions. This caused observable non-determinism in the compiler for
large bitcode programs. Basically, opt -mergefuncs program.bc | md5sum produces
different hashes when run repeatedly on the same machine. Differing output was
observed on three large bitcodes, but it was less frequent on the smallest file.
It is possible that this only manifests on the large inputs, hence remaining
undetected until now.
This patch fixes this by removing (almost, see below) all places where
comparisons between pointers are used to order functions. Most of these changes
are local, but the comparison of global values requires assigning an identifier
to each local in the order it is visited. This is very similar to the way the
comparison function identifies Value*'s defined within a function. Because the
order of visiting the functions and their subparts is deterministic, the
identifiers assigned to the globals will be as well, and the order of functions
will be deterministic.
With these changes, there is no more observed non-determinism. There is also
only minor slowdowns (negligible to 4%) compared to the baseline, which is
likely a result of the fact that global comparisons involve hash lookups and not
just pointer comparisons.
The one caveat so far is that programs containing BlockAddress constants can
still be non-deterministic. It is not clear what the right solution is here. In
particular, even if the global numbers are used to order by function, we still
need a way to order the BasicBlock*'s. Unfortunately, we cannot just bail out
and fail to order the functions or consider them equal, because we require a
total order over functions. Note that programs with BlockAddress constants are
relatively rare, so the impact of leaving this in is minor as long as this pass
is opt-in.
Author: jrkoenig
Reviewers: nlewycky, jfb, dschuff
Subscribers: jevinskie, llvm-commits, chapuni
Differential revision: http://reviews.llvm.org/D12168
llvm-svn: 245762
2015-08-22 07:27:24 +08:00
|
|
|
FunctionNode(Function *F)
|
|
|
|
: F(F), Hash(FunctionComparator::functionHash(*F)) {}
|
2017-10-20 05:21:30 +08:00
|
|
|
|
2014-06-22 04:54:36 +08:00
|
|
|
Function *getFunc() const { return F; }
|
Improve the determinism of MergeFunctions
Summary:
Merge functions previously relied on unsigned comparisons of pointer values to
order functions. This caused observable non-determinism in the compiler for
large bitcode programs. Basically, opt -mergefuncs program.bc | md5sum produces
different hashes when run repeatedly on the same machine. Differing output was
observed on three large bitcodes, but it was less frequent on the smallest file.
It is possible that this only manifests on the large inputs, hence remaining
undetected until now.
This patch fixes this by removing (almost, see below) all places where
comparisons between pointers are used to order functions. Most of these changes
are local, but the comparison of global values requires assigning an identifier
to each local in the order it is visited. This is very similar to the way the
comparison function identifies Value*'s defined within a function. Because the
order of visiting the functions and their subparts is deterministic, the
identifiers assigned to the globals will be as well, and the order of functions
will be deterministic.
With these changes, there is no more observed non-determinism. There is also
only minor slowdowns (negligible to 4%) compared to the baseline, which is
likely a result of the fact that global comparisons involve hash lookups and not
just pointer comparisons.
The one caveat so far is that programs containing BlockAddress constants can
still be non-deterministic. It is not clear what the right solution is here. In
particular, even if the global numbers are used to order by function, we still
need a way to order the BasicBlock*'s. Unfortunately, we cannot just bail out
and fail to order the functions or consider them equal, because we require a
total order over functions. Note that programs with BlockAddress constants are
relatively rare, so the impact of leaving this in is minor as long as this pass
is opt-in.
Author: jrkoenig
Reviewers: nlewycky, jfb, dschuff
Subscribers: jevinskie, llvm-commits, chapuni
Differential revision: http://reviews.llvm.org/D12168
llvm-svn: 245762
2015-08-22 07:27:24 +08:00
|
|
|
FunctionComparator::FunctionHash getHash() const { return Hash; }
|
2015-06-09 08:03:29 +08:00
|
|
|
|
|
|
|
/// Replace the reference to the function F by the function G, assuming their
|
|
|
|
/// implementations are equal.
|
|
|
|
void replaceBy(Function *G) const {
|
|
|
|
F = G;
|
|
|
|
}
|
|
|
|
|
2015-10-07 07:24:35 +08:00
|
|
|
void release() { F = nullptr; }
|
2014-06-22 04:54:36 +08:00
|
|
|
};
|
2011-01-28 15:36:21 +08:00
|
|
|
|
|
|
|
/// MergeFunctions finds functions which will generate identical machine code,
|
|
|
|
/// by considering all pointer types to be equivalent. Once identified,
|
|
|
|
/// MergeFunctions will fold them by replacing a call to one to a call to a
|
|
|
|
/// bitcast of the other.
|
|
|
|
class MergeFunctions : public ModulePass {
|
|
|
|
public:
|
|
|
|
static char ID;
|
2017-10-20 05:21:30 +08:00
|
|
|
|
2011-01-28 15:36:21 +08:00
|
|
|
MergeFunctions()
|
2017-10-20 05:21:30 +08:00
|
|
|
: ModulePass(ID), FnTree(FunctionNodeCmp(&GlobalNumbers)) {
|
2011-01-28 15:36:21 +08:00
|
|
|
initializeMergeFunctionsPass(*PassRegistry::getPassRegistry());
|
|
|
|
}
|
|
|
|
|
2014-03-05 17:10:37 +08:00
|
|
|
bool runOnModule(Module &M) override;
|
2011-01-28 15:36:21 +08:00
|
|
|
|
|
|
|
private:
|
Improve the determinism of MergeFunctions
Summary:
Merge functions previously relied on unsigned comparisons of pointer values to
order functions. This caused observable non-determinism in the compiler for
large bitcode programs. Basically, opt -mergefuncs program.bc | md5sum produces
different hashes when run repeatedly on the same machine. Differing output was
observed on three large bitcodes, but it was less frequent on the smallest file.
It is possible that this only manifests on the large inputs, hence remaining
undetected until now.
This patch fixes this by removing (almost, see below) all places where
comparisons between pointers are used to order functions. Most of these changes
are local, but the comparison of global values requires assigning an identifier
to each local in the order it is visited. This is very similar to the way the
comparison function identifies Value*'s defined within a function. Because the
order of visiting the functions and their subparts is deterministic, the
identifiers assigned to the globals will be as well, and the order of functions
will be deterministic.
With these changes, there is no more observed non-determinism. There is also
only minor slowdowns (negligible to 4%) compared to the baseline, which is
likely a result of the fact that global comparisons involve hash lookups and not
just pointer comparisons.
The one caveat so far is that programs containing BlockAddress constants can
still be non-deterministic. It is not clear what the right solution is here. In
particular, even if the global numbers are used to order by function, we still
need a way to order the BasicBlock*'s. Unfortunately, we cannot just bail out
and fail to order the functions or consider them equal, because we require a
total order over functions. Note that programs with BlockAddress constants are
relatively rare, so the impact of leaving this in is minor as long as this pass
is opt-in.
Author: jrkoenig
Reviewers: nlewycky, jfb, dschuff
Subscribers: jevinskie, llvm-commits, chapuni
Differential revision: http://reviews.llvm.org/D12168
llvm-svn: 245762
2015-08-22 07:27:24 +08:00
|
|
|
// The function comparison operator is provided here so that FunctionNodes do
|
|
|
|
// not need to become larger with another pointer.
|
|
|
|
class FunctionNodeCmp {
|
|
|
|
GlobalNumberState* GlobalNumbers;
|
2017-10-20 05:21:30 +08:00
|
|
|
|
Improve the determinism of MergeFunctions
Summary:
Merge functions previously relied on unsigned comparisons of pointer values to
order functions. This caused observable non-determinism in the compiler for
large bitcode programs. Basically, opt -mergefuncs program.bc | md5sum produces
different hashes when run repeatedly on the same machine. Differing output was
observed on three large bitcodes, but it was less frequent on the smallest file.
It is possible that this only manifests on the large inputs, hence remaining
undetected until now.
This patch fixes this by removing (almost, see below) all places where
comparisons between pointers are used to order functions. Most of these changes
are local, but the comparison of global values requires assigning an identifier
to each local in the order it is visited. This is very similar to the way the
comparison function identifies Value*'s defined within a function. Because the
order of visiting the functions and their subparts is deterministic, the
identifiers assigned to the globals will be as well, and the order of functions
will be deterministic.
With these changes, there is no more observed non-determinism. There is also
only minor slowdowns (negligible to 4%) compared to the baseline, which is
likely a result of the fact that global comparisons involve hash lookups and not
just pointer comparisons.
The one caveat so far is that programs containing BlockAddress constants can
still be non-deterministic. It is not clear what the right solution is here. In
particular, even if the global numbers are used to order by function, we still
need a way to order the BasicBlock*'s. Unfortunately, we cannot just bail out
and fail to order the functions or consider them equal, because we require a
total order over functions. Note that programs with BlockAddress constants are
relatively rare, so the impact of leaving this in is minor as long as this pass
is opt-in.
Author: jrkoenig
Reviewers: nlewycky, jfb, dschuff
Subscribers: jevinskie, llvm-commits, chapuni
Differential revision: http://reviews.llvm.org/D12168
llvm-svn: 245762
2015-08-22 07:27:24 +08:00
|
|
|
public:
|
|
|
|
FunctionNodeCmp(GlobalNumberState* GN) : GlobalNumbers(GN) {}
|
2017-10-20 05:21:30 +08:00
|
|
|
|
Improve the determinism of MergeFunctions
Summary:
Merge functions previously relied on unsigned comparisons of pointer values to
order functions. This caused observable non-determinism in the compiler for
large bitcode programs. Basically, opt -mergefuncs program.bc | md5sum produces
different hashes when run repeatedly on the same machine. Differing output was
observed on three large bitcodes, but it was less frequent on the smallest file.
It is possible that this only manifests on the large inputs, hence remaining
undetected until now.
This patch fixes this by removing (almost, see below) all places where
comparisons between pointers are used to order functions. Most of these changes
are local, but the comparison of global values requires assigning an identifier
to each local in the order it is visited. This is very similar to the way the
comparison function identifies Value*'s defined within a function. Because the
order of visiting the functions and their subparts is deterministic, the
identifiers assigned to the globals will be as well, and the order of functions
will be deterministic.
With these changes, there is no more observed non-determinism. There is also
only minor slowdowns (negligible to 4%) compared to the baseline, which is
likely a result of the fact that global comparisons involve hash lookups and not
just pointer comparisons.
The one caveat so far is that programs containing BlockAddress constants can
still be non-deterministic. It is not clear what the right solution is here. In
particular, even if the global numbers are used to order by function, we still
need a way to order the BasicBlock*'s. Unfortunately, we cannot just bail out
and fail to order the functions or consider them equal, because we require a
total order over functions. Note that programs with BlockAddress constants are
relatively rare, so the impact of leaving this in is minor as long as this pass
is opt-in.
Author: jrkoenig
Reviewers: nlewycky, jfb, dschuff
Subscribers: jevinskie, llvm-commits, chapuni
Differential revision: http://reviews.llvm.org/D12168
llvm-svn: 245762
2015-08-22 07:27:24 +08:00
|
|
|
bool operator()(const FunctionNode &LHS, const FunctionNode &RHS) const {
|
|
|
|
// Order first by hashes, then full function comparison.
|
|
|
|
if (LHS.getHash() != RHS.getHash())
|
|
|
|
return LHS.getHash() < RHS.getHash();
|
|
|
|
FunctionComparator FCmp(LHS.getFunc(), RHS.getFunc(), GlobalNumbers);
|
|
|
|
return FCmp.compare() == -1;
|
|
|
|
}
|
|
|
|
};
|
2017-10-20 05:21:30 +08:00
|
|
|
using FnTreeType = std::set<FunctionNode, FunctionNodeCmp>;
|
Improve the determinism of MergeFunctions
Summary:
Merge functions previously relied on unsigned comparisons of pointer values to
order functions. This caused observable non-determinism in the compiler for
large bitcode programs. Basically, opt -mergefuncs program.bc | md5sum produces
different hashes when run repeatedly on the same machine. Differing output was
observed on three large bitcodes, but it was less frequent on the smallest file.
It is possible that this only manifests on the large inputs, hence remaining
undetected until now.
This patch fixes this by removing (almost, see below) all places where
comparisons between pointers are used to order functions. Most of these changes
are local, but the comparison of global values requires assigning an identifier
to each local in the order it is visited. This is very similar to the way the
comparison function identifies Value*'s defined within a function. Because the
order of visiting the functions and their subparts is deterministic, the
identifiers assigned to the globals will be as well, and the order of functions
will be deterministic.
With these changes, there is no more observed non-determinism. There is also
only minor slowdowns (negligible to 4%) compared to the baseline, which is
likely a result of the fact that global comparisons involve hash lookups and not
just pointer comparisons.
The one caveat so far is that programs containing BlockAddress constants can
still be non-deterministic. It is not clear what the right solution is here. In
particular, even if the global numbers are used to order by function, we still
need a way to order the BasicBlock*'s. Unfortunately, we cannot just bail out
and fail to order the functions or consider them equal, because we require a
total order over functions. Note that programs with BlockAddress constants are
relatively rare, so the impact of leaving this in is minor as long as this pass
is opt-in.
Author: jrkoenig
Reviewers: nlewycky, jfb, dschuff
Subscribers: jevinskie, llvm-commits, chapuni
Differential revision: http://reviews.llvm.org/D12168
llvm-svn: 245762
2015-08-22 07:27:24 +08:00
|
|
|
|
|
|
|
GlobalNumberState GlobalNumbers;
|
2011-01-28 15:36:21 +08:00
|
|
|
|
|
|
|
/// A work queue of functions that may have been modified and should be
|
|
|
|
/// analyzed again.
|
2017-05-02 01:07:49 +08:00
|
|
|
std::vector<WeakTrackingVH> Deferred;
|
2011-01-28 15:36:21 +08:00
|
|
|
|
2017-10-20 05:21:30 +08:00
|
|
|
#ifndef NDEBUG
|
2014-06-22 02:58:11 +08:00
|
|
|
/// Checks the rules of order relation introduced among functions set.
|
|
|
|
/// Returns true, if sanity check has been passed, and false if failed.
|
2017-05-02 01:07:49 +08:00
|
|
|
bool doSanityCheck(std::vector<WeakTrackingVH> &Worklist);
|
2017-04-29 03:39:45 +08:00
|
|
|
#endif
|
2014-06-22 02:58:11 +08:00
|
|
|
|
2014-06-22 04:54:36 +08:00
|
|
|
/// Insert a ComparableFunction into the FnTree, or merge it away if it's
|
2011-01-28 15:36:21 +08:00
|
|
|
/// equal to one that's already present.
|
2014-06-22 04:54:36 +08:00
|
|
|
bool insert(Function *NewFunction);
|
2011-01-28 15:36:21 +08:00
|
|
|
|
2014-06-22 04:54:36 +08:00
|
|
|
/// Remove a Function from the FnTree and queue it up for a second sweep of
|
2011-01-28 15:36:21 +08:00
|
|
|
/// analysis.
|
2011-01-28 16:43:14 +08:00
|
|
|
void remove(Function *F);
|
2011-01-28 15:36:21 +08:00
|
|
|
|
2014-06-22 04:54:36 +08:00
|
|
|
/// Find the functions that use this Value and remove them from FnTree and
|
2011-01-28 15:36:21 +08:00
|
|
|
/// queue the functions.
|
2011-01-28 16:43:14 +08:00
|
|
|
void removeUsers(Value *V);
|
2011-01-28 15:36:21 +08:00
|
|
|
|
|
|
|
/// Replace all direct calls of Old with calls of New. Will bitcast New if
|
|
|
|
/// necessary to make types match.
|
|
|
|
void replaceDirectCallers(Function *Old, Function *New);
|
|
|
|
|
2011-01-28 16:43:14 +08:00
|
|
|
/// Merge two equivalent functions. Upon completion, G may be deleted, or may
|
|
|
|
/// be converted into a thunk. In either case, it should never be visited
|
|
|
|
/// again.
|
|
|
|
void mergeTwoFunctions(Function *F, Function *G);
|
2011-01-28 15:36:21 +08:00
|
|
|
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
/// Fill PDIUnrelatedWL with instructions from the entry block that are
|
|
|
|
/// unrelated to parameter related debug info.
|
|
|
|
void filterInstsUnrelatedToPDI(BasicBlock *GEntryBlock,
|
|
|
|
std::vector<Instruction *> &PDIUnrelatedWL);
|
|
|
|
|
|
|
|
/// Erase the rest of the CFG (i.e. barring the entry block).
|
|
|
|
void eraseTail(Function *G);
|
|
|
|
|
|
|
|
/// Erase the instructions in PDIUnrelatedWL as they are unrelated to the
|
|
|
|
/// parameter debug info, from the entry block.
|
|
|
|
void eraseInstsUnrelatedToPDI(std::vector<Instruction *> &PDIUnrelatedWL);
|
|
|
|
|
|
|
|
/// Replace G with a simple tail call to bitcast(F). Also (unless
|
|
|
|
/// MergeFunctionsPDI holds) replace direct uses of G with bitcast(F),
|
|
|
|
/// delete G.
|
2011-01-28 16:43:14 +08:00
|
|
|
void writeThunk(Function *F, Function *G);
|
2011-01-28 15:36:21 +08:00
|
|
|
|
2015-06-09 08:03:29 +08:00
|
|
|
/// Replace function F with function G in the function tree.
|
2015-09-03 07:55:23 +08:00
|
|
|
void replaceFunctionInTree(const FunctionNode &FN, Function *G);
|
2015-06-09 08:03:29 +08:00
|
|
|
|
2011-01-28 16:43:14 +08:00
|
|
|
/// The set of all distinct functions. Use the insert() and remove() methods
|
2015-09-03 07:55:23 +08:00
|
|
|
/// to modify it. The map allows efficient lookup and deferring of Functions.
|
2014-06-22 04:54:36 +08:00
|
|
|
FnTreeType FnTree;
|
2017-10-20 05:21:30 +08:00
|
|
|
|
2015-09-03 07:55:23 +08:00
|
|
|
// Map functions to the iterators of the FunctionNode which contains them
|
|
|
|
// in the FnTree. This must be updated carefully whenever the FnTree is
|
|
|
|
// modified, i.e. in insert(), remove(), and replaceFunctionInTree(), to avoid
|
|
|
|
// dangling iterators into FnTree. The invariant that preserves this is that
|
|
|
|
// there is exactly one mapping F -> FN for each FunctionNode FN in FnTree.
|
|
|
|
ValueMap<Function*, FnTreeType::iterator> FNodesInTree;
|
2011-01-28 15:36:21 +08:00
|
|
|
};
|
|
|
|
|
2015-10-07 07:24:35 +08:00
|
|
|
} // end anonymous namespace
|
2011-01-28 15:36:21 +08:00
|
|
|
|
|
|
|
char MergeFunctions::ID = 0;
|
2017-10-20 05:21:30 +08:00
|
|
|
|
2011-01-28 15:36:21 +08:00
|
|
|
INITIALIZE_PASS(MergeFunctions, "mergefunc", "Merge Functions", false, false)
|
|
|
|
|
|
|
|
ModulePass *llvm::createMergeFunctionsPass() {
|
|
|
|
return new MergeFunctions();
|
|
|
|
}
|
|
|
|
|
2017-04-29 03:39:45 +08:00
|
|
|
#ifndef NDEBUG
|
2017-05-02 01:07:49 +08:00
|
|
|
bool MergeFunctions::doSanityCheck(std::vector<WeakTrackingVH> &Worklist) {
|
2014-06-22 02:58:11 +08:00
|
|
|
if (const unsigned Max = NumFunctionsForSanityCheck) {
|
|
|
|
unsigned TripleNumber = 0;
|
|
|
|
bool Valid = true;
|
|
|
|
|
|
|
|
dbgs() << "MERGEFUNC-SANITY: Started for first " << Max << " functions.\n";
|
|
|
|
|
|
|
|
unsigned i = 0;
|
2017-05-02 01:07:49 +08:00
|
|
|
for (std::vector<WeakTrackingVH>::iterator I = Worklist.begin(),
|
|
|
|
E = Worklist.end();
|
2014-06-22 02:58:11 +08:00
|
|
|
I != E && i < Max; ++I, ++i) {
|
|
|
|
unsigned j = i;
|
2017-05-02 01:07:49 +08:00
|
|
|
for (std::vector<WeakTrackingVH>::iterator J = I; J != E && j < Max;
|
|
|
|
++J, ++j) {
|
2014-06-22 02:58:11 +08:00
|
|
|
Function *F1 = cast<Function>(*I);
|
|
|
|
Function *F2 = cast<Function>(*J);
|
Improve the determinism of MergeFunctions
Summary:
Merge functions previously relied on unsigned comparisons of pointer values to
order functions. This caused observable non-determinism in the compiler for
large bitcode programs. Basically, opt -mergefuncs program.bc | md5sum produces
different hashes when run repeatedly on the same machine. Differing output was
observed on three large bitcodes, but it was less frequent on the smallest file.
It is possible that this only manifests on the large inputs, hence remaining
undetected until now.
This patch fixes this by removing (almost, see below) all places where
comparisons between pointers are used to order functions. Most of these changes
are local, but the comparison of global values requires assigning an identifier
to each local in the order it is visited. This is very similar to the way the
comparison function identifies Value*'s defined within a function. Because the
order of visiting the functions and their subparts is deterministic, the
identifiers assigned to the globals will be as well, and the order of functions
will be deterministic.
With these changes, there is no more observed non-determinism. There is also
only minor slowdowns (negligible to 4%) compared to the baseline, which is
likely a result of the fact that global comparisons involve hash lookups and not
just pointer comparisons.
The one caveat so far is that programs containing BlockAddress constants can
still be non-deterministic. It is not clear what the right solution is here. In
particular, even if the global numbers are used to order by function, we still
need a way to order the BasicBlock*'s. Unfortunately, we cannot just bail out
and fail to order the functions or consider them equal, because we require a
total order over functions. Note that programs with BlockAddress constants are
relatively rare, so the impact of leaving this in is minor as long as this pass
is opt-in.
Author: jrkoenig
Reviewers: nlewycky, jfb, dschuff
Subscribers: jevinskie, llvm-commits, chapuni
Differential revision: http://reviews.llvm.org/D12168
llvm-svn: 245762
2015-08-22 07:27:24 +08:00
|
|
|
int Res1 = FunctionComparator(F1, F2, &GlobalNumbers).compare();
|
|
|
|
int Res2 = FunctionComparator(F2, F1, &GlobalNumbers).compare();
|
2014-06-22 02:58:11 +08:00
|
|
|
|
|
|
|
// If F1 <= F2, then F2 >= F1, otherwise report failure.
|
|
|
|
if (Res1 != -Res2) {
|
|
|
|
dbgs() << "MERGEFUNC-SANITY: Non-symmetric; triple: " << TripleNumber
|
|
|
|
<< "\n";
|
2017-01-28 14:53:55 +08:00
|
|
|
dbgs() << *F1 << '\n' << *F2 << '\n';
|
2014-06-22 02:58:11 +08:00
|
|
|
Valid = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (Res1 == 0)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
unsigned k = j;
|
2017-05-02 01:07:49 +08:00
|
|
|
for (std::vector<WeakTrackingVH>::iterator K = J; K != E && k < Max;
|
2014-06-22 02:58:11 +08:00
|
|
|
++k, ++K, ++TripleNumber) {
|
|
|
|
if (K == J)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
Function *F3 = cast<Function>(*K);
|
Improve the determinism of MergeFunctions
Summary:
Merge functions previously relied on unsigned comparisons of pointer values to
order functions. This caused observable non-determinism in the compiler for
large bitcode programs. Basically, opt -mergefuncs program.bc | md5sum produces
different hashes when run repeatedly on the same machine. Differing output was
observed on three large bitcodes, but it was less frequent on the smallest file.
It is possible that this only manifests on the large inputs, hence remaining
undetected until now.
This patch fixes this by removing (almost, see below) all places where
comparisons between pointers are used to order functions. Most of these changes
are local, but the comparison of global values requires assigning an identifier
to each local in the order it is visited. This is very similar to the way the
comparison function identifies Value*'s defined within a function. Because the
order of visiting the functions and their subparts is deterministic, the
identifiers assigned to the globals will be as well, and the order of functions
will be deterministic.
With these changes, there is no more observed non-determinism. There is also
only minor slowdowns (negligible to 4%) compared to the baseline, which is
likely a result of the fact that global comparisons involve hash lookups and not
just pointer comparisons.
The one caveat so far is that programs containing BlockAddress constants can
still be non-deterministic. It is not clear what the right solution is here. In
particular, even if the global numbers are used to order by function, we still
need a way to order the BasicBlock*'s. Unfortunately, we cannot just bail out
and fail to order the functions or consider them equal, because we require a
total order over functions. Note that programs with BlockAddress constants are
relatively rare, so the impact of leaving this in is minor as long as this pass
is opt-in.
Author: jrkoenig
Reviewers: nlewycky, jfb, dschuff
Subscribers: jevinskie, llvm-commits, chapuni
Differential revision: http://reviews.llvm.org/D12168
llvm-svn: 245762
2015-08-22 07:27:24 +08:00
|
|
|
int Res3 = FunctionComparator(F1, F3, &GlobalNumbers).compare();
|
|
|
|
int Res4 = FunctionComparator(F2, F3, &GlobalNumbers).compare();
|
2014-06-22 02:58:11 +08:00
|
|
|
|
|
|
|
bool Transitive = true;
|
|
|
|
|
|
|
|
if (Res1 != 0 && Res1 == Res4) {
|
2014-06-22 03:07:51 +08:00
|
|
|
// F1 > F2, F2 > F3 => F1 > F3
|
2014-06-22 02:58:11 +08:00
|
|
|
Transitive = Res3 == Res1;
|
2014-06-22 03:07:51 +08:00
|
|
|
} else if (Res3 != 0 && Res3 == -Res4) {
|
|
|
|
// F1 > F3, F3 > F2 => F1 > F2
|
2014-06-22 02:58:11 +08:00
|
|
|
Transitive = Res3 == Res1;
|
2014-06-22 03:07:51 +08:00
|
|
|
} else if (Res4 != 0 && -Res3 == Res4) {
|
|
|
|
// F2 > F3, F3 > F1 => F2 > F1
|
2014-06-22 02:58:11 +08:00
|
|
|
Transitive = Res4 == -Res1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!Transitive) {
|
|
|
|
dbgs() << "MERGEFUNC-SANITY: Non-transitive; triple: "
|
|
|
|
<< TripleNumber << "\n";
|
|
|
|
dbgs() << "Res1, Res3, Res4: " << Res1 << ", " << Res3 << ", "
|
|
|
|
<< Res4 << "\n";
|
2017-01-28 14:53:55 +08:00
|
|
|
dbgs() << *F1 << '\n' << *F2 << '\n' << *F3 << '\n';
|
2014-06-22 02:58:11 +08:00
|
|
|
Valid = false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
dbgs() << "MERGEFUNC-SANITY: " << (Valid ? "Passed." : "Failed.") << "\n";
|
|
|
|
return Valid;
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
2017-04-29 03:39:45 +08:00
|
|
|
#endif
|
2014-06-22 02:58:11 +08:00
|
|
|
|
2011-01-28 15:36:21 +08:00
|
|
|
bool MergeFunctions::runOnModule(Module &M) {
|
2016-04-23 06:06:11 +08:00
|
|
|
if (skipModule(M))
|
|
|
|
return false;
|
|
|
|
|
2011-01-28 15:36:21 +08:00
|
|
|
bool Changed = false;
|
|
|
|
|
Accelerate MergeFunctions with hashing
This patch makes the Merge Functions pass faster by calculating and comparing
a hash value which captures the essential structure of a function before
performing a full function comparison.
The hash is calculated by hashing the function signature, then walking the basic
blocks of the function in the same order as the main comparison function. The
opcode of each instruction is hashed in sequence, which means that different
functions according to the existing total order cannot have the same hash, as
the comparison requires the opcodes of the two functions to be the same order.
The hash function is a static member of the FunctionComparator class because it
is tightly coupled to the exact comparison function used. For example, functions
which are equivalent modulo a single variant callsite might be merged by a more
aggressive MergeFunctions, and the hash function would need to be insensitive to
these differences in order to exploit this.
The hashing function uses a utility class which accumulates the values into an
internal state using a standard bit-mixing function. Note that this is a different interface
than a regular hashing routine, because the values to be hashed are scattered
amongst the properties of a llvm::Function, not linear in memory. This scheme is
fast because only one word of state needs to be kept, and the mixing function is
a few instructions.
The main runOnModule function first computes the hash of each function, and only
further processes functions which do not have a unique function hash. The hash
is also used to order the sorted function set. If the hashes differ, their
values are used to order the functions, otherwise the full comparison is done.
Both of these are helpful in speeding up MergeFunctions. Together they result in
speedups of 9% for mysqld (a mostly C application with little redundancy), 46%
for libxul in Firefox, and 117% for Chromium. (These are all LTO builds.) In all
three cases, the new speed of MergeFunctions is about half that of the module
verifier, making it relatively inexpensive even for large LTO builds with
hundreds of thousands of functions. The same functions are merged, so this
change is free performance.
Author: jrkoenig
Reviewers: nlewycky, dschuff, jfb
Subscribers: llvm-commits, aemerson
Differential revision: http://reviews.llvm.org/D11923
llvm-svn: 245140
2015-08-15 09:18:18 +08:00
|
|
|
// All functions in the module, ordered by hash. Functions with a unique
|
|
|
|
// hash value are easily eliminated.
|
|
|
|
std::vector<std::pair<FunctionComparator::FunctionHash, Function *>>
|
|
|
|
HashedFuncs;
|
|
|
|
for (Function &Func : M) {
|
|
|
|
if (!Func.isDeclaration() && !Func.hasAvailableExternallyLinkage()) {
|
|
|
|
HashedFuncs.push_back({FunctionComparator::functionHash(Func), &Func});
|
|
|
|
}
|
2011-01-28 15:36:21 +08:00
|
|
|
}
|
|
|
|
|
2015-08-16 10:41:23 +08:00
|
|
|
std::stable_sort(
|
|
|
|
HashedFuncs.begin(), HashedFuncs.end(),
|
|
|
|
[](const std::pair<FunctionComparator::FunctionHash, Function *> &a,
|
|
|
|
const std::pair<FunctionComparator::FunctionHash, Function *> &b) {
|
|
|
|
return a.first < b.first;
|
|
|
|
});
|
Accelerate MergeFunctions with hashing
This patch makes the Merge Functions pass faster by calculating and comparing
a hash value which captures the essential structure of a function before
performing a full function comparison.
The hash is calculated by hashing the function signature, then walking the basic
blocks of the function in the same order as the main comparison function. The
opcode of each instruction is hashed in sequence, which means that different
functions according to the existing total order cannot have the same hash, as
the comparison requires the opcodes of the two functions to be the same order.
The hash function is a static member of the FunctionComparator class because it
is tightly coupled to the exact comparison function used. For example, functions
which are equivalent modulo a single variant callsite might be merged by a more
aggressive MergeFunctions, and the hash function would need to be insensitive to
these differences in order to exploit this.
The hashing function uses a utility class which accumulates the values into an
internal state using a standard bit-mixing function. Note that this is a different interface
than a regular hashing routine, because the values to be hashed are scattered
amongst the properties of a llvm::Function, not linear in memory. This scheme is
fast because only one word of state needs to be kept, and the mixing function is
a few instructions.
The main runOnModule function first computes the hash of each function, and only
further processes functions which do not have a unique function hash. The hash
is also used to order the sorted function set. If the hashes differ, their
values are used to order the functions, otherwise the full comparison is done.
Both of these are helpful in speeding up MergeFunctions. Together they result in
speedups of 9% for mysqld (a mostly C application with little redundancy), 46%
for libxul in Firefox, and 117% for Chromium. (These are all LTO builds.) In all
three cases, the new speed of MergeFunctions is about half that of the module
verifier, making it relatively inexpensive even for large LTO builds with
hundreds of thousands of functions. The same functions are merged, so this
change is free performance.
Author: jrkoenig
Reviewers: nlewycky, dschuff, jfb
Subscribers: llvm-commits, aemerson
Differential revision: http://reviews.llvm.org/D11923
llvm-svn: 245140
2015-08-15 09:18:18 +08:00
|
|
|
|
|
|
|
auto S = HashedFuncs.begin();
|
|
|
|
for (auto I = HashedFuncs.begin(), IE = HashedFuncs.end(); I != IE; ++I) {
|
|
|
|
// If the hash value matches the previous value or the next one, we must
|
|
|
|
// consider merging it. Otherwise it is dropped and never considered again.
|
|
|
|
if ((I != S && std::prev(I)->first == I->first) ||
|
|
|
|
(std::next(I) != IE && std::next(I)->first == I->first) ) {
|
2017-05-02 01:07:49 +08:00
|
|
|
Deferred.push_back(WeakTrackingVH(I->second));
|
Accelerate MergeFunctions with hashing
This patch makes the Merge Functions pass faster by calculating and comparing
a hash value which captures the essential structure of a function before
performing a full function comparison.
The hash is calculated by hashing the function signature, then walking the basic
blocks of the function in the same order as the main comparison function. The
opcode of each instruction is hashed in sequence, which means that different
functions according to the existing total order cannot have the same hash, as
the comparison requires the opcodes of the two functions to be the same order.
The hash function is a static member of the FunctionComparator class because it
is tightly coupled to the exact comparison function used. For example, functions
which are equivalent modulo a single variant callsite might be merged by a more
aggressive MergeFunctions, and the hash function would need to be insensitive to
these differences in order to exploit this.
The hashing function uses a utility class which accumulates the values into an
internal state using a standard bit-mixing function. Note that this is a different interface
than a regular hashing routine, because the values to be hashed are scattered
amongst the properties of a llvm::Function, not linear in memory. This scheme is
fast because only one word of state needs to be kept, and the mixing function is
a few instructions.
The main runOnModule function first computes the hash of each function, and only
further processes functions which do not have a unique function hash. The hash
is also used to order the sorted function set. If the hashes differ, their
values are used to order the functions, otherwise the full comparison is done.
Both of these are helpful in speeding up MergeFunctions. Together they result in
speedups of 9% for mysqld (a mostly C application with little redundancy), 46%
for libxul in Firefox, and 117% for Chromium. (These are all LTO builds.) In all
three cases, the new speed of MergeFunctions is about half that of the module
verifier, making it relatively inexpensive even for large LTO builds with
hundreds of thousands of functions. The same functions are merged, so this
change is free performance.
Author: jrkoenig
Reviewers: nlewycky, dschuff, jfb
Subscribers: llvm-commits, aemerson
Differential revision: http://reviews.llvm.org/D11923
llvm-svn: 245140
2015-08-15 09:18:18 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-01-28 15:36:21 +08:00
|
|
|
do {
|
2017-05-02 01:07:49 +08:00
|
|
|
std::vector<WeakTrackingVH> Worklist;
|
2011-01-28 15:36:21 +08:00
|
|
|
Deferred.swap(Worklist);
|
|
|
|
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(doSanityCheck(Worklist));
|
2014-06-22 02:58:11 +08:00
|
|
|
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(dbgs() << "size of module: " << M.size() << '\n');
|
|
|
|
LLVM_DEBUG(dbgs() << "size of worklist: " << Worklist.size() << '\n');
|
2011-01-28 15:36:21 +08:00
|
|
|
|
2016-06-01 01:20:23 +08:00
|
|
|
// Insert functions and merge them.
|
2017-05-02 01:07:49 +08:00
|
|
|
for (WeakTrackingVH &I : Worklist) {
|
2016-06-26 20:28:59 +08:00
|
|
|
if (!I)
|
|
|
|
continue;
|
|
|
|
Function *F = cast<Function>(I);
|
2016-06-01 01:20:23 +08:00
|
|
|
if (!F->isDeclaration() && !F->hasAvailableExternallyLinkage()) {
|
2014-06-22 04:54:36 +08:00
|
|
|
Changed |= insert(F);
|
2011-01-28 15:36:21 +08:00
|
|
|
}
|
|
|
|
}
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(dbgs() << "size of FnTree: " << FnTree.size() << '\n');
|
2011-01-28 15:36:21 +08:00
|
|
|
} while (!Deferred.empty());
|
|
|
|
|
2014-06-22 04:54:36 +08:00
|
|
|
FnTree.clear();
|
2015-10-06 01:26:36 +08:00
|
|
|
GlobalNumbers.clear();
|
2011-01-28 15:36:21 +08:00
|
|
|
|
|
|
|
return Changed;
|
|
|
|
}
|
|
|
|
|
2011-01-28 16:43:14 +08:00
|
|
|
// Replace direct callers of Old with New.
|
2011-01-25 16:56:50 +08:00
|
|
|
void MergeFunctions::replaceDirectCallers(Function *Old, Function *New) {
|
|
|
|
Constant *BitcastNew = ConstantExpr::getBitCast(New, Old->getType());
|
2014-03-09 11:16:01 +08:00
|
|
|
for (auto UI = Old->use_begin(), UE = Old->use_end(); UI != UE;) {
|
|
|
|
Use *U = &*UI;
|
2011-01-25 16:56:50 +08:00
|
|
|
++UI;
|
2014-03-09 11:16:01 +08:00
|
|
|
CallSite CS(U->getUser());
|
|
|
|
if (CS && CS.isCallee(U)) {
|
2015-07-22 01:07:07 +08:00
|
|
|
// Transfer the called function's attributes to the call site. Due to the
|
2015-09-11 02:08:35 +08:00
|
|
|
// bitcast we will 'lose' ABI changing attributes because the 'called
|
2015-07-22 01:07:07 +08:00
|
|
|
// function' is no longer a Function* but the bitcast. Code that looks up
|
|
|
|
// the attributes from the called function will fail.
|
2015-09-11 02:08:35 +08:00
|
|
|
|
|
|
|
// FIXME: This is not actually true, at least not anymore. The callsite
|
|
|
|
// will always have the same ABI affecting attributes as the callee,
|
|
|
|
// because otherwise the original input has UB. Note that Old and New
|
|
|
|
// always have matching ABI, so no attributes need to be changed.
|
|
|
|
// Transferring other attributes may help other optimizations, but that
|
|
|
|
// should be done uniformly and not in this ad-hoc way.
|
2015-07-22 01:07:07 +08:00
|
|
|
auto &Context = New->getContext();
|
2017-04-14 07:12:13 +08:00
|
|
|
auto NewPAL = New->getAttributes();
|
|
|
|
SmallVector<AttributeSet, 4> NewArgAttrs;
|
|
|
|
for (unsigned argIdx = 0; argIdx < CS.arg_size(); argIdx++)
|
|
|
|
NewArgAttrs.push_back(NewPAL.getParamAttributes(argIdx));
|
|
|
|
// Don't transfer attributes from the function to the callee. Function
|
|
|
|
// attributes typically aren't relevant to the calling convention or ABI.
|
|
|
|
CS.setAttributes(AttributeList::get(Context, /*FnAttrs=*/AttributeSet(),
|
|
|
|
NewPAL.getRetAttributes(),
|
|
|
|
NewArgAttrs));
|
2015-07-22 01:07:07 +08:00
|
|
|
|
2011-01-28 16:43:14 +08:00
|
|
|
remove(CS.getInstruction()->getParent()->getParent());
|
2014-03-09 11:16:01 +08:00
|
|
|
U->set(BitcastNew);
|
2011-01-25 16:56:50 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-09-17 17:36:11 +08:00
|
|
|
// Helper for writeThunk,
|
|
|
|
// Selects proper bitcast operation,
|
2014-01-25 01:20:08 +08:00
|
|
|
// but a bit simpler then CastInst::getCastOpcode.
|
2016-03-14 05:05:13 +08:00
|
|
|
static Value *createCast(IRBuilder<> &Builder, Value *V, Type *DestTy) {
|
2013-09-17 17:36:11 +08:00
|
|
|
Type *SrcTy = V->getType();
|
2014-05-01 01:53:04 +08:00
|
|
|
if (SrcTy->isStructTy()) {
|
|
|
|
assert(DestTy->isStructTy());
|
|
|
|
assert(SrcTy->getStructNumElements() == DestTy->getStructNumElements());
|
|
|
|
Value *Result = UndefValue::get(DestTy);
|
|
|
|
for (unsigned int I = 0, E = SrcTy->getStructNumElements(); I < E; ++I) {
|
|
|
|
Value *Element = createCast(
|
2014-08-27 13:25:25 +08:00
|
|
|
Builder, Builder.CreateExtractValue(V, makeArrayRef(I)),
|
2014-05-01 01:53:04 +08:00
|
|
|
DestTy->getStructElementType(I));
|
|
|
|
|
|
|
|
Result =
|
2014-08-27 13:25:25 +08:00
|
|
|
Builder.CreateInsertValue(Result, Element, makeArrayRef(I));
|
2014-05-01 01:53:04 +08:00
|
|
|
}
|
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
assert(!DestTy->isStructTy());
|
2013-09-17 17:36:11 +08:00
|
|
|
if (SrcTy->isIntegerTy() && DestTy->isPointerTy())
|
|
|
|
return Builder.CreateIntToPtr(V, DestTy);
|
|
|
|
else if (SrcTy->isPointerTy() && DestTy->isIntegerTy())
|
|
|
|
return Builder.CreatePtrToInt(V, DestTy);
|
|
|
|
else
|
|
|
|
return Builder.CreateBitCast(V, DestTy);
|
|
|
|
}
|
|
|
|
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
// Erase the instructions in PDIUnrelatedWL as they are unrelated to the
|
|
|
|
// parameter debug info, from the entry block.
|
|
|
|
void MergeFunctions::eraseInstsUnrelatedToPDI(
|
|
|
|
std::vector<Instruction *> &PDIUnrelatedWL) {
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(
|
|
|
|
dbgs() << " Erasing instructions (in reverse order of appearance in "
|
|
|
|
"entry block) unrelated to parameter debug info from entry "
|
|
|
|
"block: {\n");
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
while (!PDIUnrelatedWL.empty()) {
|
|
|
|
Instruction *I = PDIUnrelatedWL.back();
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(dbgs() << " Deleting Instruction: ");
|
|
|
|
LLVM_DEBUG(I->print(dbgs()));
|
|
|
|
LLVM_DEBUG(dbgs() << "\n");
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
I->eraseFromParent();
|
|
|
|
PDIUnrelatedWL.pop_back();
|
|
|
|
}
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(dbgs() << " } // Done erasing instructions unrelated to parameter "
|
|
|
|
"debug info from entry block. \n");
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Reduce G to its entry block.
|
|
|
|
void MergeFunctions::eraseTail(Function *G) {
|
|
|
|
std::vector<BasicBlock *> WorklistBB;
|
|
|
|
for (Function::iterator BBI = std::next(G->begin()), BBE = G->end();
|
|
|
|
BBI != BBE; ++BBI) {
|
|
|
|
BBI->dropAllReferences();
|
|
|
|
WorklistBB.push_back(&*BBI);
|
|
|
|
}
|
|
|
|
while (!WorklistBB.empty()) {
|
|
|
|
BasicBlock *BB = WorklistBB.back();
|
|
|
|
BB->eraseFromParent();
|
|
|
|
WorklistBB.pop_back();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// We are interested in the following instructions from the entry block as being
|
|
|
|
// related to parameter debug info:
|
|
|
|
// - @llvm.dbg.declare
|
|
|
|
// - stores from the incoming parameters to locations on the stack-frame
|
|
|
|
// - allocas that create these locations on the stack-frame
|
|
|
|
// - @llvm.dbg.value
|
|
|
|
// - the entry block's terminator
|
|
|
|
// The rest are unrelated to debug info for the parameters; fill up
|
|
|
|
// PDIUnrelatedWL with such instructions.
|
|
|
|
void MergeFunctions::filterInstsUnrelatedToPDI(
|
|
|
|
BasicBlock *GEntryBlock, std::vector<Instruction *> &PDIUnrelatedWL) {
|
|
|
|
std::set<Instruction *> PDIRelated;
|
|
|
|
for (BasicBlock::iterator BI = GEntryBlock->begin(), BIE = GEntryBlock->end();
|
|
|
|
BI != BIE; ++BI) {
|
|
|
|
if (auto *DVI = dyn_cast<DbgValueInst>(&*BI)) {
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(dbgs() << " Deciding: ");
|
|
|
|
LLVM_DEBUG(BI->print(dbgs()));
|
|
|
|
LLVM_DEBUG(dbgs() << "\n");
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
DILocalVariable *DILocVar = DVI->getVariable();
|
|
|
|
if (DILocVar->isParameter()) {
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(dbgs() << " Include (parameter): ");
|
|
|
|
LLVM_DEBUG(BI->print(dbgs()));
|
|
|
|
LLVM_DEBUG(dbgs() << "\n");
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
PDIRelated.insert(&*BI);
|
|
|
|
} else {
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(dbgs() << " Delete (!parameter): ");
|
|
|
|
LLVM_DEBUG(BI->print(dbgs()));
|
|
|
|
LLVM_DEBUG(dbgs() << "\n");
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
}
|
|
|
|
} else if (auto *DDI = dyn_cast<DbgDeclareInst>(&*BI)) {
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(dbgs() << " Deciding: ");
|
|
|
|
LLVM_DEBUG(BI->print(dbgs()));
|
|
|
|
LLVM_DEBUG(dbgs() << "\n");
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
DILocalVariable *DILocVar = DDI->getVariable();
|
|
|
|
if (DILocVar->isParameter()) {
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(dbgs() << " Parameter: ");
|
|
|
|
LLVM_DEBUG(DILocVar->print(dbgs()));
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
AllocaInst *AI = dyn_cast_or_null<AllocaInst>(DDI->getAddress());
|
|
|
|
if (AI) {
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(dbgs() << " Processing alloca users: ");
|
|
|
|
LLVM_DEBUG(dbgs() << "\n");
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
for (User *U : AI->users()) {
|
|
|
|
if (StoreInst *SI = dyn_cast<StoreInst>(U)) {
|
|
|
|
if (Value *Arg = SI->getValueOperand()) {
|
|
|
|
if (dyn_cast<Argument>(Arg)) {
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(dbgs() << " Include: ");
|
|
|
|
LLVM_DEBUG(AI->print(dbgs()));
|
|
|
|
LLVM_DEBUG(dbgs() << "\n");
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
PDIRelated.insert(AI);
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(dbgs() << " Include (parameter): ");
|
|
|
|
LLVM_DEBUG(SI->print(dbgs()));
|
|
|
|
LLVM_DEBUG(dbgs() << "\n");
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
PDIRelated.insert(SI);
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(dbgs() << " Include: ");
|
|
|
|
LLVM_DEBUG(BI->print(dbgs()));
|
|
|
|
LLVM_DEBUG(dbgs() << "\n");
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
PDIRelated.insert(&*BI);
|
|
|
|
} else {
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(dbgs() << " Delete (!parameter): ");
|
|
|
|
LLVM_DEBUG(SI->print(dbgs()));
|
|
|
|
LLVM_DEBUG(dbgs() << "\n");
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
} else {
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(dbgs() << " Defer: ");
|
|
|
|
LLVM_DEBUG(U->print(dbgs()));
|
|
|
|
LLVM_DEBUG(dbgs() << "\n");
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
} else {
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(dbgs() << " Delete (alloca NULL): ");
|
|
|
|
LLVM_DEBUG(BI->print(dbgs()));
|
|
|
|
LLVM_DEBUG(dbgs() << "\n");
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
}
|
|
|
|
} else {
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(dbgs() << " Delete (!parameter): ");
|
|
|
|
LLVM_DEBUG(BI->print(dbgs()));
|
|
|
|
LLVM_DEBUG(dbgs() << "\n");
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
}
|
|
|
|
} else if (dyn_cast<TerminatorInst>(BI) == GEntryBlock->getTerminator()) {
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(dbgs() << " Will Include Terminator: ");
|
|
|
|
LLVM_DEBUG(BI->print(dbgs()));
|
|
|
|
LLVM_DEBUG(dbgs() << "\n");
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
PDIRelated.insert(&*BI);
|
|
|
|
} else {
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(dbgs() << " Defer: ");
|
|
|
|
LLVM_DEBUG(BI->print(dbgs()));
|
|
|
|
LLVM_DEBUG(dbgs() << "\n");
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
}
|
|
|
|
}
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(
|
|
|
|
dbgs()
|
|
|
|
<< " Report parameter debug info related/related instructions: {\n");
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
for (BasicBlock::iterator BI = GEntryBlock->begin(), BE = GEntryBlock->end();
|
|
|
|
BI != BE; ++BI) {
|
|
|
|
|
|
|
|
Instruction *I = &*BI;
|
|
|
|
if (PDIRelated.find(I) == PDIRelated.end()) {
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(dbgs() << " !PDIRelated: ");
|
|
|
|
LLVM_DEBUG(I->print(dbgs()));
|
|
|
|
LLVM_DEBUG(dbgs() << "\n");
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
PDIUnrelatedWL.push_back(I);
|
|
|
|
} else {
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(dbgs() << " PDIRelated: ");
|
|
|
|
LLVM_DEBUG(I->print(dbgs()));
|
|
|
|
LLVM_DEBUG(dbgs() << "\n");
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
}
|
|
|
|
}
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(dbgs() << " }\n");
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
// Replace G with a simple tail call to bitcast(F). Also (unless
|
|
|
|
// MergeFunctionsPDI holds) replace direct uses of G with bitcast(F),
|
|
|
|
// delete G. Under MergeFunctionsPDI, we use G itself for creating
|
|
|
|
// the thunk as we preserve the debug info (and associated instructions)
|
|
|
|
// from G's entry block pertaining to G's incoming arguments which are
|
|
|
|
// passed on as corresponding arguments in the call that G makes to F.
|
|
|
|
// For better debugability, under MergeFunctionsPDI, we do not modify G's
|
|
|
|
// call sites to point to F even when within the same translation unit.
|
2011-01-28 16:43:14 +08:00
|
|
|
void MergeFunctions::writeThunk(Function *F, Function *G) {
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
if (!G->isInterposable() && !MergeFunctionsPDI) {
|
2017-10-15 20:29:01 +08:00
|
|
|
if (G->hasGlobalUnnamedAddr()) {
|
2017-10-19 12:47:48 +08:00
|
|
|
// G might have been a key in our GlobalNumberState, and it's illegal
|
|
|
|
// to replace a key in ValueMap<GlobalValue *> with a non-global.
|
|
|
|
GlobalNumbers.erase(G);
|
2017-10-15 20:29:01 +08:00
|
|
|
// If G's address is not significant, replace it entirely.
|
|
|
|
Constant *BitcastF = ConstantExpr::getBitCast(F, G->getType());
|
|
|
|
G->replaceAllUsesWith(BitcastF);
|
|
|
|
} else {
|
|
|
|
// Redirect direct callers of G to F. (See note on MergeFunctionsPDI
|
|
|
|
// above).
|
|
|
|
replaceDirectCallers(G, F);
|
|
|
|
}
|
2010-05-13 13:48:45 +08:00
|
|
|
}
|
|
|
|
|
2010-09-07 09:42:10 +08:00
|
|
|
// If G was internal then we may have replaced all uses of G with F. If so,
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
// stop here and delete G. There's no need for a thunk. (See note on
|
|
|
|
// MergeFunctionsPDI above).
|
|
|
|
if (G->hasLocalLinkage() && G->use_empty() && !MergeFunctionsPDI) {
|
2010-08-06 15:21:30 +08:00
|
|
|
G->eraseFromParent();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2017-10-15 20:29:09 +08:00
|
|
|
// Don't merge tiny functions using a thunk, since it can just end up
|
|
|
|
// making the function larger.
|
|
|
|
if (F->size() == 1) {
|
|
|
|
if (F->front().size() <= 2) {
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(dbgs() << "writeThunk: " << F->getName()
|
|
|
|
<< " is too small to bother creating a thunk for\n");
|
2017-10-15 20:29:09 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
BasicBlock *GEntryBlock = nullptr;
|
|
|
|
std::vector<Instruction *> PDIUnrelatedWL;
|
|
|
|
BasicBlock *BB = nullptr;
|
|
|
|
Function *NewG = nullptr;
|
|
|
|
if (MergeFunctionsPDI) {
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(dbgs() << "writeThunk: (MergeFunctionsPDI) Do not create a new "
|
|
|
|
"function as thunk; retain original: "
|
|
|
|
<< G->getName() << "()\n");
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
GEntryBlock = &G->getEntryBlock();
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(
|
|
|
|
dbgs() << "writeThunk: (MergeFunctionsPDI) filter parameter related "
|
|
|
|
"debug info for "
|
|
|
|
<< G->getName() << "() {\n");
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
filterInstsUnrelatedToPDI(GEntryBlock, PDIUnrelatedWL);
|
|
|
|
GEntryBlock->getTerminator()->eraseFromParent();
|
|
|
|
BB = GEntryBlock;
|
|
|
|
} else {
|
|
|
|
NewG = Function::Create(G->getFunctionType(), G->getLinkage(), "",
|
|
|
|
G->getParent());
|
|
|
|
BB = BasicBlock::Create(F->getContext(), "", NewG);
|
|
|
|
}
|
2009-06-12 16:04:51 +08:00
|
|
|
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
IRBuilder<> Builder(BB);
|
|
|
|
Function *H = MergeFunctionsPDI ? G : NewG;
|
2010-05-13 13:48:45 +08:00
|
|
|
SmallVector<Value *, 16> Args;
|
2009-06-12 16:04:51 +08:00
|
|
|
unsigned i = 0;
|
2011-07-18 12:54:35 +08:00
|
|
|
FunctionType *FFTy = F->getFunctionType();
|
2017-10-20 05:21:30 +08:00
|
|
|
for (Argument &AI : H->args()) {
|
2015-10-14 01:51:03 +08:00
|
|
|
Args.push_back(createCast(Builder, &AI, FFTy->getParamType(i)));
|
2009-06-12 16:04:51 +08:00
|
|
|
++i;
|
2008-11-02 13:52:50 +08:00
|
|
|
}
|
|
|
|
|
2011-07-15 16:37:34 +08:00
|
|
|
CallInst *CI = Builder.CreateCall(F, Args);
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
ReturnInst *RI = nullptr;
|
2009-06-12 16:04:51 +08:00
|
|
|
CI->setTailCall();
|
2009-06-13 00:04:00 +08:00
|
|
|
CI->setCallingConv(F->getCallingConv());
|
2015-09-11 02:08:35 +08:00
|
|
|
CI->setAttributes(F->getAttributes());
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
if (H->getReturnType()->isVoidTy()) {
|
|
|
|
RI = Builder.CreateRetVoid();
|
2009-06-12 16:04:51 +08:00
|
|
|
} else {
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
RI = Builder.CreateRet(createCast(Builder, CI, H->getReturnType()));
|
2008-11-03 00:46:26 +08:00
|
|
|
}
|
|
|
|
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
if (MergeFunctionsPDI) {
|
|
|
|
DISubprogram *DIS = G->getSubprogram();
|
|
|
|
if (DIS) {
|
|
|
|
DebugLoc CIDbgLoc = DebugLoc::get(DIS->getScopeLine(), 0, DIS);
|
|
|
|
DebugLoc RIDbgLoc = DebugLoc::get(DIS->getScopeLine(), 0, DIS);
|
|
|
|
CI->setDebugLoc(CIDbgLoc);
|
|
|
|
RI->setDebugLoc(RIDbgLoc);
|
|
|
|
} else {
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(
|
|
|
|
dbgs() << "writeThunk: (MergeFunctionsPDI) No DISubprogram for "
|
|
|
|
<< G->getName() << "()\n");
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
}
|
|
|
|
eraseTail(G);
|
|
|
|
eraseInstsUnrelatedToPDI(PDIUnrelatedWL);
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(
|
|
|
|
dbgs() << "} // End of parameter related debug info filtering for: "
|
|
|
|
<< G->getName() << "()\n");
|
MergeFunctions: Preserve debug info in thunks, under option -mergefunc-preserve-debug-info
Summary:
Under option -mergefunc-preserve-debug-info we:
- Do not create a new function for a thunk.
- Retain the debug info for a thunk's parameters (and associated
instructions for the debug info) from the entry block.
Note: -debug will display the algorithm at work.
- Create debug-info for the call (to the shared implementation) made by
a thunk and its return value.
- Erase the rest of the function, retaining the (minimally sized) entry
block to create a thunk.
- Preserve a thunk's call site to point to the thunk even when both occur
within the same translation unit, to aid debugability. Note that this
behaviour differs from the underlying -mergefunc implementation which
modifies the thunk's call site to point to the shared implementation
when both occur within the same translation unit.
Reviewers: echristo, eeckstein, dblaikie, aprantl, friss
Reviewed By: aprantl
Subscribers: davide, fhahn, jfb, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D28075
llvm-svn: 292702
2017-01-21 10:02:56 +08:00
|
|
|
} else {
|
|
|
|
NewG->copyAttributesFrom(G);
|
|
|
|
NewG->takeName(G);
|
|
|
|
removeUsers(G);
|
|
|
|
G->replaceAllUsesWith(NewG);
|
|
|
|
G->eraseFromParent();
|
|
|
|
}
|
2010-09-07 09:42:10 +08:00
|
|
|
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(dbgs() << "writeThunk: " << H->getName() << '\n');
|
2010-09-07 09:42:10 +08:00
|
|
|
++NumThunksWritten;
|
2008-11-02 13:52:50 +08:00
|
|
|
}
|
|
|
|
|
2011-01-28 16:43:14 +08:00
|
|
|
// Merge two equivalent functions. Upon completion, Function G is deleted.
|
|
|
|
void MergeFunctions::mergeTwoFunctions(Function *F, Function *G) {
|
Don't IPO over functions that can be de-refined
Summary:
Fixes PR26774.
If you're aware of the issue, feel free to skip the "Motivation"
section and jump directly to "This patch".
Motivation:
I define "refinement" as discarding behaviors from a program that the
optimizer has license to discard. So transforming:
```
void f(unsigned x) {
unsigned t = 5 / x;
(void)t;
}
```
to
```
void f(unsigned x) { }
```
is refinement, since the behavior went from "if x == 0 then undefined
else nothing" to "nothing" (the optimizer has license to discard
undefined behavior).
Refinement is a fundamental aspect of many mid-level optimizations done
by LLVM. For instance, transforming `x == (x + 1)` to `false` also
involves refinement since the expression's value went from "if x is
`undef` then { `true` or `false` } else { `false` }" to "`false`" (by
definition, the optimizer has license to fold `undef` to any non-`undef`
value).
Unfortunately, refinement implies that the optimizer cannot assume
that the implementation of a function it can see has all of the
behavior an unoptimized or a differently optimized version of the same
function can have. This is a problem for functions with comdat
linkage, where a function can be replaced by an unoptimized or a
differently optimized version of the same source level function.
For instance, FunctionAttrs cannot assume a comdat function is
actually `readnone` even if it does not have any loads or stores in
it; since there may have been loads and stores in the "original
function" that were refined out in the currently visible variant, and
at the link step the linker may in fact choose an implementation with
a load or a store. As an example, consider a function that does two
atomic loads from the same memory location, and writes to memory only
if the two values are not equal. The optimizer is allowed to refine
this function by first CSE'ing the two loads, and the folding the
comparision to always report that the two values are equal. Such a
refined variant will look like it is `readonly`. However, the
unoptimized version of the function can still write to memory (since
the two loads //can// result in different values), and selecting the
unoptimized version at link time will retroactively invalidate
transforms we may have done under the assumption that the function
does not write to memory.
Note: this is not just a problem with atomics or with linking
differently optimized object files. See PR26774 for more realistic
examples that involved neither.
This patch:
This change introduces a new set of linkage types, predicated as
`GlobalValue::mayBeDerefined` that returns true if the linkage type
allows a function to be replaced by a differently optimized variant at
link time. It then changes a set of IPO passes to bail out if they see
such a function.
Reviewers: chandlerc, hfinkel, dexonsmith, joker.eph, rnk
Subscribers: mcrosier, llvm-commits
Differential Revision: http://reviews.llvm.org/D18634
llvm-svn: 265762
2016-04-08 08:48:30 +08:00
|
|
|
if (F->isInterposable()) {
|
|
|
|
assert(G->isInterposable());
|
2009-06-12 23:56:56 +08:00
|
|
|
|
2015-06-10 02:19:17 +08:00
|
|
|
// Make them both thunks to the same internal function.
|
|
|
|
Function *H = Function::Create(F->getFunctionType(), F->getLinkage(), "",
|
|
|
|
F->getParent());
|
|
|
|
H->copyAttributesFrom(F);
|
|
|
|
H->takeName(F);
|
|
|
|
removeUsers(F);
|
|
|
|
F->replaceAllUsesWith(H);
|
2009-06-12 23:56:56 +08:00
|
|
|
|
2015-06-10 02:19:17 +08:00
|
|
|
unsigned MaxAlignment = std::max(G->getAlignment(), H->getAlignment());
|
2010-08-10 05:03:28 +08:00
|
|
|
|
2017-07-28 03:36:13 +08:00
|
|
|
writeThunk(F, G);
|
|
|
|
writeThunk(F, H);
|
2010-09-07 09:42:10 +08:00
|
|
|
|
2015-06-10 02:19:17 +08:00
|
|
|
F->setAlignment(MaxAlignment);
|
|
|
|
F->setLinkage(GlobalValue::PrivateLinkage);
|
2010-09-07 09:42:10 +08:00
|
|
|
++NumDoubleWeak;
|
2010-08-06 15:21:30 +08:00
|
|
|
} else {
|
2017-07-28 03:36:13 +08:00
|
|
|
writeThunk(F, G);
|
2008-11-02 13:52:50 +08:00
|
|
|
}
|
|
|
|
|
2009-06-12 16:04:51 +08:00
|
|
|
++NumFunctionsMerged;
|
2008-11-02 13:52:50 +08:00
|
|
|
}
|
|
|
|
|
2015-09-03 07:55:23 +08:00
|
|
|
/// Replace function F by function G.
|
|
|
|
void MergeFunctions::replaceFunctionInTree(const FunctionNode &FN,
|
2015-06-09 08:03:29 +08:00
|
|
|
Function *G) {
|
2015-09-03 07:55:23 +08:00
|
|
|
Function *F = FN.getFunc();
|
Improve the determinism of MergeFunctions
Summary:
Merge functions previously relied on unsigned comparisons of pointer values to
order functions. This caused observable non-determinism in the compiler for
large bitcode programs. Basically, opt -mergefuncs program.bc | md5sum produces
different hashes when run repeatedly on the same machine. Differing output was
observed on three large bitcodes, but it was less frequent on the smallest file.
It is possible that this only manifests on the large inputs, hence remaining
undetected until now.
This patch fixes this by removing (almost, see below) all places where
comparisons between pointers are used to order functions. Most of these changes
are local, but the comparison of global values requires assigning an identifier
to each local in the order it is visited. This is very similar to the way the
comparison function identifies Value*'s defined within a function. Because the
order of visiting the functions and their subparts is deterministic, the
identifiers assigned to the globals will be as well, and the order of functions
will be deterministic.
With these changes, there is no more observed non-determinism. There is also
only minor slowdowns (negligible to 4%) compared to the baseline, which is
likely a result of the fact that global comparisons involve hash lookups and not
just pointer comparisons.
The one caveat so far is that programs containing BlockAddress constants can
still be non-deterministic. It is not clear what the right solution is here. In
particular, even if the global numbers are used to order by function, we still
need a way to order the BasicBlock*'s. Unfortunately, we cannot just bail out
and fail to order the functions or consider them equal, because we require a
total order over functions. Note that programs with BlockAddress constants are
relatively rare, so the impact of leaving this in is minor as long as this pass
is opt-in.
Author: jrkoenig
Reviewers: nlewycky, jfb, dschuff
Subscribers: jevinskie, llvm-commits, chapuni
Differential revision: http://reviews.llvm.org/D12168
llvm-svn: 245762
2015-08-22 07:27:24 +08:00
|
|
|
assert(FunctionComparator(F, G, &GlobalNumbers).compare() == 0 &&
|
|
|
|
"The two functions must be equal");
|
2015-09-03 07:55:23 +08:00
|
|
|
|
|
|
|
auto I = FNodesInTree.find(F);
|
|
|
|
assert(I != FNodesInTree.end() && "F should be in FNodesInTree");
|
|
|
|
assert(FNodesInTree.count(G) == 0 && "FNodesInTree should not contain G");
|
|
|
|
|
|
|
|
FnTreeType::iterator IterToFNInFnTree = I->second;
|
|
|
|
assert(&(*IterToFNInFnTree) == &FN && "F should map to FN in FNodesInTree.");
|
|
|
|
// Remove F -> FN and insert G -> FN
|
|
|
|
FNodesInTree.erase(I);
|
|
|
|
FNodesInTree.insert({G, IterToFNInFnTree});
|
|
|
|
// Replace F with G in FN, which is stored inside the FnTree.
|
|
|
|
FN.replaceBy(G);
|
2015-06-09 08:03:29 +08:00
|
|
|
}
|
|
|
|
|
2014-06-22 04:54:36 +08:00
|
|
|
// Insert a ComparableFunction into the FnTree, or merge it away if equal to one
|
2011-01-28 16:43:14 +08:00
|
|
|
// that was already inserted.
|
2014-06-22 04:54:36 +08:00
|
|
|
bool MergeFunctions::insert(Function *NewFunction) {
|
|
|
|
std::pair<FnTreeType::iterator, bool> Result =
|
2015-03-10 10:37:25 +08:00
|
|
|
FnTree.insert(FunctionNode(NewFunction));
|
2014-06-22 04:54:36 +08:00
|
|
|
|
2011-02-09 14:32:02 +08:00
|
|
|
if (Result.second) {
|
2015-09-03 07:55:23 +08:00
|
|
|
assert(FNodesInTree.count(NewFunction) == 0);
|
|
|
|
FNodesInTree.insert({NewFunction, Result.first});
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(dbgs() << "Inserting as unique: " << NewFunction->getName()
|
|
|
|
<< '\n');
|
2010-09-05 16:22:49 +08:00
|
|
|
return false;
|
2011-02-09 14:32:02 +08:00
|
|
|
}
|
2010-08-31 13:53:05 +08:00
|
|
|
|
2014-09-10 18:08:25 +08:00
|
|
|
const FunctionNode &OldF = *Result.first;
|
2010-09-05 16:22:49 +08:00
|
|
|
|
2015-06-09 08:03:29 +08:00
|
|
|
// Impose a total order (by name) on the replacement of functions. This is
|
|
|
|
// important when operating on more than one module independently to prevent
|
|
|
|
// cycles of thunks calling each other when the modules are linked together.
|
|
|
|
//
|
2016-06-01 01:20:23 +08:00
|
|
|
// First of all, we process strong functions before weak functions.
|
|
|
|
if ((OldF.getFunc()->isInterposable() && !NewFunction->isInterposable()) ||
|
|
|
|
(OldF.getFunc()->isInterposable() == NewFunction->isInterposable() &&
|
|
|
|
OldF.getFunc()->getName() > NewFunction->getName())) {
|
|
|
|
// Swap the two functions.
|
|
|
|
Function *F = OldF.getFunc();
|
|
|
|
replaceFunctionInTree(*Result.first, NewFunction);
|
|
|
|
NewFunction = F;
|
|
|
|
assert(OldF.getFunc() != F && "Must have swapped the functions.");
|
|
|
|
}
|
2010-09-05 16:22:49 +08:00
|
|
|
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(dbgs() << " " << OldF.getFunc()->getName()
|
|
|
|
<< " == " << NewFunction->getName() << '\n');
|
2010-09-05 16:22:49 +08:00
|
|
|
|
2014-06-22 04:54:36 +08:00
|
|
|
Function *DeleteF = NewFunction;
|
2011-01-28 16:43:14 +08:00
|
|
|
mergeTwoFunctions(OldF.getFunc(), DeleteF);
|
2010-09-05 16:22:49 +08:00
|
|
|
return true;
|
2010-08-08 13:04:23 +08:00
|
|
|
}
|
2009-06-12 16:04:51 +08:00
|
|
|
|
2014-06-22 04:54:36 +08:00
|
|
|
// Remove a function from FnTree. If it was already in FnTree, add
|
|
|
|
// it to Deferred so that we'll look at it in the next round.
|
2011-01-28 16:43:14 +08:00
|
|
|
void MergeFunctions::remove(Function *F) {
|
2015-09-03 07:55:23 +08:00
|
|
|
auto I = FNodesInTree.find(F);
|
|
|
|
if (I != FNodesInTree.end()) {
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(dbgs() << "Deferred " << F->getName() << ".\n");
|
2015-09-03 07:55:23 +08:00
|
|
|
FnTree.erase(I->second);
|
|
|
|
// I->second has been invalidated, remove it from the FNodesInTree map to
|
|
|
|
// preserve the invariant.
|
|
|
|
FNodesInTree.erase(I);
|
2015-05-30 03:43:39 +08:00
|
|
|
Deferred.emplace_back(F);
|
2010-08-31 13:53:05 +08:00
|
|
|
}
|
2011-01-02 10:46:33 +08:00
|
|
|
}
|
2010-09-05 16:22:49 +08:00
|
|
|
|
2011-01-28 16:43:14 +08:00
|
|
|
// For each instruction used by the value, remove() the function that contains
|
|
|
|
// the instruction. This should happen right before a call to RAUW.
|
|
|
|
void MergeFunctions::removeUsers(Value *V) {
|
2011-01-03 03:16:44 +08:00
|
|
|
std::vector<Value *> Worklist;
|
|
|
|
Worklist.push_back(V);
|
2015-07-16 05:51:33 +08:00
|
|
|
SmallSet<Value*, 8> Visited;
|
|
|
|
Visited.insert(V);
|
2011-01-03 03:16:44 +08:00
|
|
|
while (!Worklist.empty()) {
|
|
|
|
Value *V = Worklist.back();
|
|
|
|
Worklist.pop_back();
|
|
|
|
|
2014-03-09 11:16:01 +08:00
|
|
|
for (User *U : V->users()) {
|
|
|
|
if (Instruction *I = dyn_cast<Instruction>(U)) {
|
2011-01-28 16:43:14 +08:00
|
|
|
remove(I->getParent()->getParent());
|
2014-03-09 11:16:01 +08:00
|
|
|
} else if (isa<GlobalValue>(U)) {
|
2011-01-15 18:16:23 +08:00
|
|
|
// do nothing
|
2014-03-09 11:16:01 +08:00
|
|
|
} else if (Constant *C = dyn_cast<Constant>(U)) {
|
2015-07-16 05:51:33 +08:00
|
|
|
for (User *UU : C->users()) {
|
|
|
|
if (!Visited.insert(UU).second)
|
|
|
|
Worklist.push_back(UU);
|
|
|
|
}
|
2011-01-03 03:16:44 +08:00
|
|
|
}
|
2010-09-05 16:22:49 +08:00
|
|
|
}
|
2010-08-31 13:53:05 +08:00
|
|
|
}
|
2010-09-05 16:22:49 +08:00
|
|
|
}
|