2008-11-02 13:52:50 +08:00
|
|
|
//===- MergeFunctions.cpp - Merge identical functions ---------------------===//
|
|
|
|
//
|
2019-01-19 16:50:56 +08:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2008-11-02 13:52:50 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// 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.
|
2018-07-31 03:41:25 +08:00
|
|
|
//
|
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"
|
2018-06-12 19:16:56 +08:00
|
|
|
#include "llvm/ADT/SmallPtrSet.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"
|
Sink all InitializePasses.h includes
This file lists every pass in LLVM, and is included by Pass.h, which is
very popular. Every time we add, remove, or rename a pass in LLVM, it
caused lots of recompilation.
I found this fact by looking at this table, which is sorted by the
number of times a file was changed over the last 100,000 git commits
multiplied by the number of object files that depend on it in the
current checkout:
recompiles touches affected_files header
342380 95 3604 llvm/include/llvm/ADT/STLExtras.h
314730 234 1345 llvm/include/llvm/InitializePasses.h
307036 118 2602 llvm/include/llvm/ADT/APInt.h
213049 59 3611 llvm/include/llvm/Support/MathExtras.h
170422 47 3626 llvm/include/llvm/Support/Compiler.h
162225 45 3605 llvm/include/llvm/ADT/Optional.h
158319 63 2513 llvm/include/llvm/ADT/Triple.h
140322 39 3598 llvm/include/llvm/ADT/StringRef.h
137647 59 2333 llvm/include/llvm/Support/Error.h
131619 73 1803 llvm/include/llvm/Support/FileSystem.h
Before this change, touching InitializePasses.h would cause 1345 files
to recompile. After this change, touching it only causes 550 compiles in
an incremental rebuild.
Reviewers: bkramer, asbirlea, bollu, jdoerfert
Differential Revision: https://reviews.llvm.org/D70211
2019-11-14 05:15:01 +08:00
|
|
|
#include "llvm/InitializePasses.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"
|
2020-01-11 04:52:19 +08:00
|
|
|
#include "llvm/Transforms/IPO/MergeFunctions.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");
|
2018-11-22 03:37:19 +08:00
|
|
|
STATISTIC(NumAliasesWritten, "Number of aliases generated");
|
2010-09-07 09:42:10 +08:00
|
|
|
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."));
|
|
|
|
|
2018-11-22 03:37:19 +08:00
|
|
|
static cl::opt<bool>
|
|
|
|
MergeFunctionsAliases("mergefunc-use-aliases", cl::Hidden,
|
|
|
|
cl::init(false),
|
|
|
|
cl::desc("Allow mergefunc to create aliases"));
|
|
|
|
|
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;
|
|
|
|
}
|
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.
|
2020-01-11 04:52:19 +08:00
|
|
|
class MergeFunctions {
|
2011-01-28 15:36:21 +08:00
|
|
|
public:
|
2020-01-11 04:52:19 +08:00
|
|
|
MergeFunctions() : FnTree(FunctionNodeCmp(&GlobalNumbers)) {
|
2011-01-28 15:36:21 +08:00
|
|
|
}
|
|
|
|
|
2020-01-11 04:52:19 +08:00
|
|
|
bool runOnModule(Module &M);
|
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
|
|
|
|
2018-11-22 03:37:19 +08:00
|
|
|
// Replace G with an alias to F (deleting function G)
|
|
|
|
void writeAlias(Function *F, Function *G);
|
|
|
|
|
2019-01-19 10:46:22 +08:00
|
|
|
// Replace G with an alias to F if possible, or a thunk to F if possible.
|
|
|
|
// Returns false if neither is the case.
|
2018-11-22 03:37:19 +08:00
|
|
|
bool writeThunkOrAlias(Function *F, Function *G);
|
|
|
|
|
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.
|
[MergeFuncs] Improve ordering of equal functions
Summary:
MergeFunctions currently tries to process strong functions before
weak functions, because weak functions can simply call strong
functions, while a strong/weak function cannot call a weak function
(a backing strong function is needed).
This patch additionally tries to process external functions before
local functions, because we definitely have to keep the external
function, but may be able to drop the local one (and definitely
can if it is also unnamed_addr).
Unfortunately, this exposes an existing bug in the implementation:
The FnTree and FNodesInTree structures can currently go out of
sync in the case where two weak functions are merged, because the
function in FnTree/FNodesInTree is RAUWed. This leaves it behind in
FnTree (this is intended, as it is the strong backing function which
should be used for further merges), while it is replaced in
FNodesInTree (this is not intended).
This is fixed by switching FNodesInTree from using a ValueMap to
using a DenseMap of AssertingVH.
This exposes another minor issue: Currently FNodesInTree is not
cleared after MergeFunctions finishes running. Currently, this is
potentially dangerous (e.g. if something else wants to RAUW a function
with a non-function), but at the very least it is unnecessary/inefficient.
After the change to use AssertingVH it becomes more problematic,
because there are certainly passes that remove functions.
This issue is fixed by clearing FNodesInTree at the end of the pass.
Reviewers: jfb, whitequark
Reviewed By: whitequark
Subscribers: rkruppe, llvm-commits
Differential Revision: https://reviews.llvm.org/D53271
llvm-svn: 346386
2018-11-08 11:58:01 +08:00
|
|
|
DenseMap<AssertingVH<Function>, FnTreeType::iterator> FNodesInTree;
|
2011-01-28 15:36:21 +08:00
|
|
|
};
|
|
|
|
|
2020-01-11 04:52:19 +08:00
|
|
|
class MergeFunctionsLegacyPass : public ModulePass {
|
|
|
|
public:
|
|
|
|
static char ID;
|
2011-01-28 15:36:21 +08:00
|
|
|
|
2020-01-11 04:52:19 +08:00
|
|
|
MergeFunctionsLegacyPass(): ModulePass(ID) {
|
|
|
|
initializeMergeFunctionsLegacyPassPass(*PassRegistry::getPassRegistry());
|
|
|
|
}
|
2017-10-20 05:21:30 +08:00
|
|
|
|
2020-01-11 04:52:19 +08:00
|
|
|
bool runOnModule(Module &M) override {
|
|
|
|
if (skipModule(M))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
MergeFunctions MF;
|
|
|
|
return MF.runOnModule(M);
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
} // end anonymous namespace
|
|
|
|
|
|
|
|
char MergeFunctionsLegacyPass::ID = 0;
|
|
|
|
INITIALIZE_PASS(MergeFunctionsLegacyPass, "mergefunc",
|
|
|
|
"Merge Functions", false, false)
|
2011-01-28 15:36:21 +08:00
|
|
|
|
|
|
|
ModulePass *llvm::createMergeFunctionsPass() {
|
2020-01-11 04:52:19 +08:00
|
|
|
return new MergeFunctionsLegacyPass();
|
|
|
|
}
|
|
|
|
|
|
|
|
PreservedAnalyses MergeFunctionsPass::run(Module &M,
|
|
|
|
ModuleAnalysisManager &AM) {
|
|
|
|
MergeFunctions MF;
|
|
|
|
if (!MF.runOnModule(M))
|
|
|
|
return PreservedAnalyses::all();
|
|
|
|
return PreservedAnalyses::none();
|
2011-01-28 15:36:21 +08:00
|
|
|
}
|
|
|
|
|
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
|
|
|
|
2019-01-17 10:15:05 +08:00
|
|
|
/// Check whether \p F is eligible for function merging.
|
|
|
|
static bool isEligibleForMerging(Function &F) {
|
2019-01-19 10:46:22 +08:00
|
|
|
return !F.isDeclaration() && !F.hasAvailableExternallyLinkage();
|
2019-01-17 10:15:05 +08:00
|
|
|
}
|
|
|
|
|
2011-01-28 15:36:21 +08:00
|
|
|
bool MergeFunctions::runOnModule(Module &M) {
|
|
|
|
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) {
|
2019-01-17 10:15:05 +08:00
|
|
|
if (isEligibleForMerging(Func)) {
|
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
|
|
|
HashedFuncs.push_back({FunctionComparator::functionHash(Func), &Func});
|
2018-07-31 03:41:25 +08:00
|
|
|
}
|
2011-01-28 15:36:21 +08:00
|
|
|
}
|
|
|
|
|
2019-04-23 22:51:27 +08:00
|
|
|
llvm::stable_sort(HashedFuncs, less_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
|
|
|
}
|
|
|
|
}
|
2018-07-31 03:41:25 +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();
|
[MergeFuncs] Improve ordering of equal functions
Summary:
MergeFunctions currently tries to process strong functions before
weak functions, because weak functions can simply call strong
functions, while a strong/weak function cannot call a weak function
(a backing strong function is needed).
This patch additionally tries to process external functions before
local functions, because we definitely have to keep the external
function, but may be able to drop the local one (and definitely
can if it is also unnamed_addr).
Unfortunately, this exposes an existing bug in the implementation:
The FnTree and FNodesInTree structures can currently go out of
sync in the case where two weak functions are merged, because the
function in FnTree/FNodesInTree is RAUWed. This leaves it behind in
FnTree (this is intended, as it is the strong backing function which
should be used for further merges), while it is replaced in
FNodesInTree (this is not intended).
This is fixed by switching FNodesInTree from using a ValueMap to
using a DenseMap of AssertingVH.
This exposes another minor issue: Currently FNodesInTree is not
cleared after MergeFunctions finishes running. Currently, this is
potentially dangerous (e.g. if something else wants to RAUW a function
with a non-function), but at the very least it is unnecessary/inefficient.
After the change to use AssertingVH it becomes more problematic,
because there are certainly passes that remove functions.
This issue is fixed by clearing FNodesInTree at the end of the pass.
Reviewers: jfb, whitequark
Reviewed By: whitequark
Subscribers: rkruppe, llvm-commits
Differential Revision: https://reviews.llvm.org/D53271
llvm-svn: 346386
2018-11-08 11:58:01 +08:00
|
|
|
FNodesInTree.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)) {
|
2019-12-08 19:13:52 +08:00
|
|
|
// Do not copy attributes from the called function to the call-site.
|
|
|
|
// Function comparison ensures that the attributes are the same up to
|
|
|
|
// type congruences in byval(), in which case we need to keep the byval
|
|
|
|
// type of the call-site, not the callee function.
|
2019-01-12 01:56:21 +08:00
|
|
|
remove(CS.getInstruction()->getFunction());
|
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
|
|
|
}
|
2018-10-18 08:37:37 +08:00
|
|
|
} else if (BI->isTerminator() && &*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
|
|
|
}
|
|
|
|
|
2019-01-19 10:46:22 +08:00
|
|
|
/// Whether this function may be replaced by a forwarding thunk.
|
|
|
|
static bool canCreateThunkFor(Function *F) {
|
|
|
|
if (F->isVarArg())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// Don't merge tiny functions using a thunk, since it can just end up
|
|
|
|
// making the function larger.
|
2018-05-15 19:31:07 +08:00
|
|
|
if (F->size() == 1) {
|
|
|
|
if (F->front().size() <= 2) {
|
2019-01-19 10:46:22 +08:00
|
|
|
LLVM_DEBUG(dbgs() << "canCreateThunkFor: " << F->getName()
|
2018-05-23 23:09:29 +08:00
|
|
|
<< " is too small to bother creating a thunk for\n");
|
2018-05-15 19:31:07 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
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 {
|
2018-12-18 17:52:52 +08:00
|
|
|
NewG = Function::Create(G->getFunctionType(), G->getLinkage(),
|
|
|
|
G->getAddressSpace(), "", G->getParent());
|
2019-04-19 09:48:36 +08:00
|
|
|
NewG->setComdat(G->getComdat());
|
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
|
|
|
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
|
|
|
}
|
|
|
|
|
2018-11-22 03:37:19 +08:00
|
|
|
// Whether this function may be replaced by an alias
|
|
|
|
static bool canCreateAliasFor(Function *F) {
|
|
|
|
if (!MergeFunctionsAliases || !F->hasGlobalUnnamedAddr())
|
|
|
|
return false;
|
|
|
|
|
|
|
|
// We should only see linkages supported by aliases here
|
|
|
|
assert(F->hasLocalLinkage() || F->hasExternalLinkage()
|
|
|
|
|| F->hasWeakLinkage() || F->hasLinkOnceLinkage());
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Replace G with an alias to F (deleting function G)
|
|
|
|
void MergeFunctions::writeAlias(Function *F, Function *G) {
|
|
|
|
Constant *BitcastF = ConstantExpr::getBitCast(F, G->getType());
|
|
|
|
PointerType *PtrType = G->getType();
|
|
|
|
auto *GA = GlobalAlias::create(
|
|
|
|
PtrType->getElementType(), PtrType->getAddressSpace(),
|
|
|
|
G->getLinkage(), "", BitcastF, G->getParent());
|
|
|
|
|
2019-10-15 19:24:36 +08:00
|
|
|
F->setAlignment(MaybeAlign(std::max(F->getAlignment(), G->getAlignment())));
|
2018-11-22 03:37:19 +08:00
|
|
|
GA->takeName(G);
|
|
|
|
GA->setVisibility(G->getVisibility());
|
|
|
|
GA->setUnnamedAddr(GlobalValue::UnnamedAddr::Global);
|
|
|
|
|
|
|
|
removeUsers(G);
|
|
|
|
G->replaceAllUsesWith(GA);
|
|
|
|
G->eraseFromParent();
|
|
|
|
|
|
|
|
LLVM_DEBUG(dbgs() << "writeAlias: " << GA->getName() << '\n');
|
|
|
|
++NumAliasesWritten;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Replace G with an alias to F if possible, or a thunk to F if
|
|
|
|
// profitable. Returns false if neither is the case.
|
|
|
|
bool MergeFunctions::writeThunkOrAlias(Function *F, Function *G) {
|
|
|
|
if (canCreateAliasFor(G)) {
|
|
|
|
writeAlias(F, G);
|
|
|
|
return true;
|
|
|
|
}
|
2019-01-19 10:46:22 +08:00
|
|
|
if (canCreateThunkFor(F)) {
|
2018-11-22 03:37:19 +08:00
|
|
|
writeThunk(F, G);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
|
2018-11-22 03:37:19 +08:00
|
|
|
// Both writeThunkOrAlias() calls below must succeed, either because we can
|
|
|
|
// create aliases for G and NewF, or because a thunk for F is profitable.
|
|
|
|
// F here has the same signature as NewF below, so that's what we check.
|
2019-01-19 10:46:22 +08:00
|
|
|
if (!canCreateThunkFor(F) &&
|
|
|
|
(!canCreateAliasFor(F) || !canCreateAliasFor(G)))
|
2018-05-15 19:31:07 +08:00
|
|
|
return;
|
|
|
|
|
2015-06-10 02:19:17 +08:00
|
|
|
// Make them both thunks to the same internal function.
|
2018-12-18 17:52:52 +08:00
|
|
|
Function *NewF = Function::Create(F->getFunctionType(), F->getLinkage(),
|
|
|
|
F->getAddressSpace(), "", F->getParent());
|
2018-11-22 03:37:19 +08:00
|
|
|
NewF->copyAttributesFrom(F);
|
|
|
|
NewF->takeName(F);
|
2015-06-10 02:19:17 +08:00
|
|
|
removeUsers(F);
|
2018-11-22 03:37:19 +08:00
|
|
|
F->replaceAllUsesWith(NewF);
|
2009-06-12 23:56:56 +08:00
|
|
|
|
2019-10-15 19:24:36 +08:00
|
|
|
MaybeAlign MaxAlignment(std::max(G->getAlignment(), NewF->getAlignment()));
|
2010-08-10 05:03:28 +08:00
|
|
|
|
2018-11-22 03:37:19 +08:00
|
|
|
writeThunkOrAlias(F, G);
|
|
|
|
writeThunkOrAlias(F, NewF);
|
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;
|
2018-05-15 19:31:07 +08:00
|
|
|
++NumFunctionsMerged;
|
2010-08-06 15:21:30 +08:00
|
|
|
} else {
|
2018-05-15 19:31:07 +08:00
|
|
|
// For better debugability, under MergeFunctionsPDI, we do not modify G's
|
|
|
|
// call sites to point to F even when within the same translation unit.
|
|
|
|
if (!G->isInterposable() && !MergeFunctionsPDI) {
|
|
|
|
if (G->hasGlobalUnnamedAddr()) {
|
|
|
|
// 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);
|
|
|
|
// If G's address is not significant, replace it entirely.
|
|
|
|
Constant *BitcastF = ConstantExpr::getBitCast(F, G->getType());
|
2018-11-08 11:57:55 +08:00
|
|
|
removeUsers(G);
|
2018-05-15 19:31:07 +08:00
|
|
|
G->replaceAllUsesWith(BitcastF);
|
|
|
|
} else {
|
|
|
|
// Redirect direct callers of G to F. (See note on MergeFunctionsPDI
|
|
|
|
// above).
|
|
|
|
replaceDirectCallers(G, F);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// If G was internal then we may have replaced all uses of G with F. If so,
|
|
|
|
// stop here and delete G. There's no need for a thunk. (See note on
|
|
|
|
// MergeFunctionsPDI above).
|
2019-01-12 01:56:35 +08:00
|
|
|
if (G->isDiscardableIfUnused() && G->use_empty() && !MergeFunctionsPDI) {
|
2018-05-15 19:31:07 +08:00
|
|
|
G->eraseFromParent();
|
|
|
|
++NumFunctionsMerged;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2018-11-22 03:37:19 +08:00
|
|
|
if (writeThunkOrAlias(F, G)) {
|
|
|
|
++NumFunctionsMerged;
|
2018-05-15 19:31:07 +08:00
|
|
|
}
|
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");
|
2018-07-31 03:41:25 +08:00
|
|
|
|
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");
|
2018-07-31 03:41:25 +08:00
|
|
|
|
2015-09-03 07:55:23 +08:00
|
|
|
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
|
|
|
}
|
|
|
|
|
[MergeFuncs] Improve ordering of equal functions
Summary:
MergeFunctions currently tries to process strong functions before
weak functions, because weak functions can simply call strong
functions, while a strong/weak function cannot call a weak function
(a backing strong function is needed).
This patch additionally tries to process external functions before
local functions, because we definitely have to keep the external
function, but may be able to drop the local one (and definitely
can if it is also unnamed_addr).
Unfortunately, this exposes an existing bug in the implementation:
The FnTree and FNodesInTree structures can currently go out of
sync in the case where two weak functions are merged, because the
function in FnTree/FNodesInTree is RAUWed. This leaves it behind in
FnTree (this is intended, as it is the strong backing function which
should be used for further merges), while it is replaced in
FNodesInTree (this is not intended).
This is fixed by switching FNodesInTree from using a ValueMap to
using a DenseMap of AssertingVH.
This exposes another minor issue: Currently FNodesInTree is not
cleared after MergeFunctions finishes running. Currently, this is
potentially dangerous (e.g. if something else wants to RAUW a function
with a non-function), but at the very least it is unnecessary/inefficient.
After the change to use AssertingVH it becomes more problematic,
because there are certainly passes that remove functions.
This issue is fixed by clearing FNodesInTree at the end of the pass.
Reviewers: jfb, whitequark
Reviewed By: whitequark
Subscribers: rkruppe, llvm-commits
Differential Revision: https://reviews.llvm.org/D53271
llvm-svn: 346386
2018-11-08 11:58:01 +08:00
|
|
|
// Ordering for functions that are equal under FunctionComparator
|
|
|
|
static bool isFuncOrderCorrect(const Function *F, const Function *G) {
|
|
|
|
if (F->isInterposable() != G->isInterposable()) {
|
|
|
|
// Strong before weak, because the weak function may call the strong
|
|
|
|
// one, but not the other way around.
|
|
|
|
return !F->isInterposable();
|
|
|
|
}
|
|
|
|
if (F->hasLocalLinkage() != G->hasLocalLinkage()) {
|
|
|
|
// External before local, because we definitely have to keep the external
|
|
|
|
// function, but may be able to drop the local one.
|
|
|
|
return !F->hasLocalLinkage();
|
|
|
|
}
|
|
|
|
// 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.
|
|
|
|
return F->getName() <= G->getName();
|
|
|
|
}
|
|
|
|
|
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
|
|
|
|
[MergeFuncs] Improve ordering of equal functions
Summary:
MergeFunctions currently tries to process strong functions before
weak functions, because weak functions can simply call strong
functions, while a strong/weak function cannot call a weak function
(a backing strong function is needed).
This patch additionally tries to process external functions before
local functions, because we definitely have to keep the external
function, but may be able to drop the local one (and definitely
can if it is also unnamed_addr).
Unfortunately, this exposes an existing bug in the implementation:
The FnTree and FNodesInTree structures can currently go out of
sync in the case where two weak functions are merged, because the
function in FnTree/FNodesInTree is RAUWed. This leaves it behind in
FnTree (this is intended, as it is the strong backing function which
should be used for further merges), while it is replaced in
FNodesInTree (this is not intended).
This is fixed by switching FNodesInTree from using a ValueMap to
using a DenseMap of AssertingVH.
This exposes another minor issue: Currently FNodesInTree is not
cleared after MergeFunctions finishes running. Currently, this is
potentially dangerous (e.g. if something else wants to RAUW a function
with a non-function), but at the very least it is unnecessary/inefficient.
After the change to use AssertingVH it becomes more problematic,
because there are certainly passes that remove functions.
This issue is fixed by clearing FNodesInTree at the end of the pass.
Reviewers: jfb, whitequark
Reviewed By: whitequark
Subscribers: rkruppe, llvm-commits
Differential Revision: https://reviews.llvm.org/D53271
llvm-svn: 346386
2018-11-08 11:58:01 +08:00
|
|
|
if (!isFuncOrderCorrect(OldF.getFunc(), NewFunction)) {
|
2016-06-01 01:20:23 +08:00
|
|
|
// 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) {
|
2019-04-19 15:57:51 +08:00
|
|
|
for (User *U : V->users())
|
|
|
|
if (auto *I = dyn_cast<Instruction>(U))
|
|
|
|
remove(I->getFunction());
|
2010-09-05 16:22:49 +08:00
|
|
|
}
|