2017-09-23 07:46:57 +08:00
|
|
|
//===- GlobalMerge.cpp - Internal globals merging -------------------------===//
|
2010-07-25 05:52:08 +08:00
|
|
|
//
|
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
|
2010-07-25 05:52:08 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
2017-09-23 07:46:57 +08:00
|
|
|
//
|
2010-07-25 05:52:08 +08:00
|
|
|
// This pass merges globals with internal linkage into one. This way all the
|
|
|
|
// globals which were merged into a biggest one can be addressed using offsets
|
|
|
|
// from the same base pointer (no need for separate base pointer for each of the
|
|
|
|
// global). Such a transformation can significantly reduce the register pressure
|
|
|
|
// when many globals are involved.
|
|
|
|
//
|
2012-07-24 18:51:42 +08:00
|
|
|
// For example, consider the code which touches several global variables at
|
2010-09-28 12:18:29 +08:00
|
|
|
// once:
|
2010-07-25 05:52:08 +08:00
|
|
|
//
|
|
|
|
// static int foo[N], bar[N], baz[N];
|
|
|
|
//
|
|
|
|
// for (i = 0; i < N; ++i) {
|
|
|
|
// foo[i] = bar[i] * baz[i];
|
|
|
|
// }
|
|
|
|
//
|
|
|
|
// On ARM the addresses of 3 arrays should be kept in the registers, thus
|
|
|
|
// this code has quite large register pressure (loop body):
|
|
|
|
//
|
|
|
|
// ldr r1, [r5], #4
|
|
|
|
// ldr r2, [r6], #4
|
|
|
|
// mul r1, r2, r1
|
|
|
|
// str r1, [r0], #4
|
|
|
|
//
|
|
|
|
// Pass converts the code to something like:
|
|
|
|
//
|
|
|
|
// static struct {
|
|
|
|
// int foo[N];
|
|
|
|
// int bar[N];
|
|
|
|
// int baz[N];
|
|
|
|
// } merged;
|
|
|
|
//
|
|
|
|
// for (i = 0; i < N; ++i) {
|
|
|
|
// merged.foo[i] = merged.bar[i] * merged.baz[i];
|
|
|
|
// }
|
|
|
|
//
|
|
|
|
// and in ARM code this becomes:
|
|
|
|
//
|
|
|
|
// ldr r0, [r5, #40]
|
|
|
|
// ldr r1, [r5, #80]
|
|
|
|
// mul r0, r1, r0
|
|
|
|
// str r0, [r5], #4
|
|
|
|
//
|
|
|
|
// note that we saved 2 registers here almostly "for free".
|
[GlobalMerge] Look at uses to create smaller global sets.
Instead of merging everything together, look at the users of
GlobalVariables, and try to group them by function, to create
sets of globals used "together".
Using that information, a less-aggressive alternative is to keep merging
everything together *except* globals that are only ever used alone, that
is, those for which it's clearly non-profitable to merge with others.
In my testing, grouping by Function is too aggressive, but grouping by
BasicBlock is too conservative. Anything in-between isn't trivially
available, so stick with Function grouping for now.
cl::opts are added for testing; both enabled by default.
A few of the testcases aren't testing the merging proper, but just
various edge cases when merging does occur. Update them to use the
previous grouping behavior. Also, one of the tests is unrelated to
GlobalMerge; change it accordingly.
While there, switch to r234666' flags rather than the brutal -O3.
Differential Revision: http://reviews.llvm.org/D8070
llvm-svn: 235249
2015-04-18 09:21:58 +08:00
|
|
|
//
|
|
|
|
// However, merging globals can have tradeoffs:
|
|
|
|
// - it confuses debuggers, tools, and users
|
|
|
|
// - it makes linker optimizations less useful (order files, LOHs, ...)
|
|
|
|
// - it forces usage of indexed addressing (which isn't necessarily "free")
|
|
|
|
// - it can increase register pressure when the uses are disparate enough.
|
2018-07-31 03:41:25 +08:00
|
|
|
//
|
[GlobalMerge] Look at uses to create smaller global sets.
Instead of merging everything together, look at the users of
GlobalVariables, and try to group them by function, to create
sets of globals used "together".
Using that information, a less-aggressive alternative is to keep merging
everything together *except* globals that are only ever used alone, that
is, those for which it's clearly non-profitable to merge with others.
In my testing, grouping by Function is too aggressive, but grouping by
BasicBlock is too conservative. Anything in-between isn't trivially
available, so stick with Function grouping for now.
cl::opts are added for testing; both enabled by default.
A few of the testcases aren't testing the merging proper, but just
various edge cases when merging does occur. Update them to use the
previous grouping behavior. Also, one of the tests is unrelated to
GlobalMerge; change it accordingly.
While there, switch to r234666' flags rather than the brutal -O3.
Differential Revision: http://reviews.llvm.org/D8070
llvm-svn: 235249
2015-04-18 09:21:58 +08:00
|
|
|
// We use heuristics to discover the best global grouping we can (cf cl::opts).
|
2017-09-23 07:46:57 +08:00
|
|
|
//
|
2010-09-28 12:18:29 +08:00
|
|
|
// ===---------------------------------------------------------------------===//
|
2010-07-25 05:52:08 +08:00
|
|
|
|
2017-09-23 07:46:57 +08:00
|
|
|
#include "llvm/ADT/BitVector.h"
|
[GlobalMerge] Look at uses to create smaller global sets.
Instead of merging everything together, look at the users of
GlobalVariables, and try to group them by function, to create
sets of globals used "together".
Using that information, a less-aggressive alternative is to keep merging
everything together *except* globals that are only ever used alone, that
is, those for which it's clearly non-profitable to merge with others.
In my testing, grouping by Function is too aggressive, but grouping by
BasicBlock is too conservative. Anything in-between isn't trivially
available, so stick with Function grouping for now.
cl::opts are added for testing; both enabled by default.
A few of the testcases aren't testing the merging proper, but just
various edge cases when merging does occur. Update them to use the
previous grouping behavior. Also, one of the tests is unrelated to
GlobalMerge; change it accordingly.
While there, switch to r234666' flags rather than the brutal -O3.
Differential Revision: http://reviews.llvm.org/D8070
llvm-svn: 235249
2015-04-18 09:21:58 +08:00
|
|
|
#include "llvm/ADT/DenseMap.h"
|
2013-03-19 06:30:07 +08:00
|
|
|
#include "llvm/ADT/SmallPtrSet.h"
|
2017-09-23 07:46:57 +08:00
|
|
|
#include "llvm/ADT/SmallVector.h"
|
2012-12-04 00:50:05 +08:00
|
|
|
#include "llvm/ADT/Statistic.h"
|
2017-09-23 07:46:57 +08:00
|
|
|
#include "llvm/ADT/StringRef.h"
|
|
|
|
#include "llvm/ADT/Triple.h"
|
|
|
|
#include "llvm/ADT/Twine.h"
|
2015-01-14 19:23:27 +08:00
|
|
|
#include "llvm/CodeGen/Passes.h"
|
2017-09-23 07:46:57 +08:00
|
|
|
#include "llvm/IR/BasicBlock.h"
|
2013-01-02 19:36:10 +08:00
|
|
|
#include "llvm/IR/Constants.h"
|
|
|
|
#include "llvm/IR/DataLayout.h"
|
|
|
|
#include "llvm/IR/DerivedTypes.h"
|
|
|
|
#include "llvm/IR/Function.h"
|
2017-09-23 07:46:57 +08:00
|
|
|
#include "llvm/IR/GlobalAlias.h"
|
|
|
|
#include "llvm/IR/GlobalValue.h"
|
2013-01-02 19:36:10 +08:00
|
|
|
#include "llvm/IR/GlobalVariable.h"
|
2017-09-23 07:46:57 +08:00
|
|
|
#include "llvm/IR/Instruction.h"
|
2013-01-02 19:36:10 +08:00
|
|
|
#include "llvm/IR/Module.h"
|
2017-09-23 07:46:57 +08:00
|
|
|
#include "llvm/IR/Type.h"
|
|
|
|
#include "llvm/IR/Use.h"
|
|
|
|
#include "llvm/IR/User.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"
|
2010-07-25 05:52:08 +08:00
|
|
|
#include "llvm/Pass.h"
|
2017-09-23 07:46:57 +08:00
|
|
|
#include "llvm/Support/Casting.h"
|
2013-03-19 06:30:07 +08:00
|
|
|
#include "llvm/Support/CommandLine.h"
|
[GlobalMerge] Look at uses to create smaller global sets.
Instead of merging everything together, look at the users of
GlobalVariables, and try to group them by function, to create
sets of globals used "together".
Using that information, a less-aggressive alternative is to keep merging
everything together *except* globals that are only ever used alone, that
is, those for which it's clearly non-profitable to merge with others.
In my testing, grouping by Function is too aggressive, but grouping by
BasicBlock is too conservative. Anything in-between isn't trivially
available, so stick with Function grouping for now.
cl::opts are added for testing; both enabled by default.
A few of the testcases aren't testing the merging proper, but just
various edge cases when merging does occur. Update them to use the
previous grouping behavior. Also, one of the tests is unrelated to
GlobalMerge; change it accordingly.
While there, switch to r234666' flags rather than the brutal -O3.
Differential Revision: http://reviews.llvm.org/D8070
llvm-svn: 235249
2015-04-18 09:21:58 +08:00
|
|
|
#include "llvm/Support/Debug.h"
|
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2018-03-24 07:58:19 +08:00
|
|
|
#include "llvm/Target/TargetLoweringObjectFile.h"
|
2017-09-23 07:46:57 +08:00
|
|
|
#include "llvm/Target/TargetMachine.h"
|
[GlobalMerge] Look at uses to create smaller global sets.
Instead of merging everything together, look at the users of
GlobalVariables, and try to group them by function, to create
sets of globals used "together".
Using that information, a less-aggressive alternative is to keep merging
everything together *except* globals that are only ever used alone, that
is, those for which it's clearly non-profitable to merge with others.
In my testing, grouping by Function is too aggressive, but grouping by
BasicBlock is too conservative. Anything in-between isn't trivially
available, so stick with Function grouping for now.
cl::opts are added for testing; both enabled by default.
A few of the testcases aren't testing the merging proper, but just
various edge cases when merging does occur. Update them to use the
previous grouping behavior. Also, one of the tests is unrelated to
GlobalMerge; change it accordingly.
While there, switch to r234666' flags rather than the brutal -O3.
Differential Revision: http://reviews.llvm.org/D8070
llvm-svn: 235249
2015-04-18 09:21:58 +08:00
|
|
|
#include <algorithm>
|
2017-09-23 07:46:57 +08:00
|
|
|
#include <cassert>
|
|
|
|
#include <cstddef>
|
2017-11-17 09:07:10 +08:00
|
|
|
#include <cstdint>
|
2017-09-23 07:46:57 +08:00
|
|
|
#include <string>
|
|
|
|
#include <vector>
|
|
|
|
|
2010-07-25 05:52:08 +08:00
|
|
|
using namespace llvm;
|
|
|
|
|
2014-04-22 10:55:47 +08:00
|
|
|
#define DEBUG_TYPE "global-merge"
|
|
|
|
|
2015-04-11 08:06:36 +08:00
|
|
|
// FIXME: This is only useful as a last-resort way to disable the pass.
|
2014-02-18 19:17:29 +08:00
|
|
|
static cl::opt<bool>
|
2014-06-11 14:35:26 +08:00
|
|
|
EnableGlobalMerge("enable-global-merge", cl::Hidden,
|
2015-04-11 08:06:36 +08:00
|
|
|
cl::desc("Enable the global merge pass"),
|
2014-02-18 19:17:29 +08:00
|
|
|
cl::init(true));
|
|
|
|
|
2016-05-19 12:38:56 +08:00
|
|
|
static cl::opt<unsigned>
|
|
|
|
GlobalMergeMaxOffset("global-merge-max-offset", cl::Hidden,
|
|
|
|
cl::desc("Set maximum offset for global merge pass"),
|
|
|
|
cl::init(0));
|
|
|
|
|
[GlobalMerge] Look at uses to create smaller global sets.
Instead of merging everything together, look at the users of
GlobalVariables, and try to group them by function, to create
sets of globals used "together".
Using that information, a less-aggressive alternative is to keep merging
everything together *except* globals that are only ever used alone, that
is, those for which it's clearly non-profitable to merge with others.
In my testing, grouping by Function is too aggressive, but grouping by
BasicBlock is too conservative. Anything in-between isn't trivially
available, so stick with Function grouping for now.
cl::opts are added for testing; both enabled by default.
A few of the testcases aren't testing the merging proper, but just
various edge cases when merging does occur. Update them to use the
previous grouping behavior. Also, one of the tests is unrelated to
GlobalMerge; change it accordingly.
While there, switch to r234666' flags rather than the brutal -O3.
Differential Revision: http://reviews.llvm.org/D8070
llvm-svn: 235249
2015-04-18 09:21:58 +08:00
|
|
|
static cl::opt<bool> GlobalMergeGroupByUse(
|
|
|
|
"global-merge-group-by-use", cl::Hidden,
|
|
|
|
cl::desc("Improve global merge pass to look at uses"), cl::init(true));
|
|
|
|
|
|
|
|
static cl::opt<bool> GlobalMergeIgnoreSingleUse(
|
|
|
|
"global-merge-ignore-single-use", cl::Hidden,
|
|
|
|
cl::desc("Improve global merge pass to ignore globals only used alone"),
|
|
|
|
cl::init(true));
|
|
|
|
|
2013-03-19 06:30:07 +08:00
|
|
|
static cl::opt<bool>
|
|
|
|
EnableGlobalMergeOnConst("global-merge-on-const", cl::Hidden,
|
2013-07-23 05:11:30 +08:00
|
|
|
cl::desc("Enable global merge pass on constants"),
|
|
|
|
cl::init(false));
|
2013-03-19 06:30:07 +08:00
|
|
|
|
2014-06-11 14:44:53 +08:00
|
|
|
// FIXME: this could be a transitional option, and we probably need to remove
|
|
|
|
// it if only we are sure this optimization could always benefit all targets.
|
2015-08-03 20:08:41 +08:00
|
|
|
static cl::opt<cl::boolOrDefault>
|
2014-06-11 14:44:53 +08:00
|
|
|
EnableGlobalMergeOnExternal("global-merge-on-external", cl::Hidden,
|
2015-08-03 20:08:41 +08:00
|
|
|
cl::desc("Enable global merge pass on external linkage"));
|
2014-06-11 14:44:53 +08:00
|
|
|
|
2015-02-24 03:28:45 +08:00
|
|
|
STATISTIC(NumMerged, "Number of globals merged");
|
2017-09-23 07:46:57 +08:00
|
|
|
|
2010-07-25 05:52:08 +08:00
|
|
|
namespace {
|
2017-09-23 07:46:57 +08:00
|
|
|
|
2011-10-18 01:17:43 +08:00
|
|
|
class GlobalMerge : public FunctionPass {
|
2017-09-23 07:46:57 +08:00
|
|
|
const TargetMachine *TM = nullptr;
|
|
|
|
|
2015-02-24 03:28:45 +08:00
|
|
|
// FIXME: Infer the maximum possible offset depending on the actual users
|
|
|
|
// (these max offsets are different for the users inside Thumb or ARM
|
|
|
|
// functions), see the code that passes in the offset in the ARM backend
|
|
|
|
// for more information.
|
|
|
|
unsigned MaxOffset;
|
2010-07-25 05:52:08 +08:00
|
|
|
|
2015-06-05 04:39:23 +08:00
|
|
|
/// Whether we should try to optimize for size only.
|
|
|
|
/// Currently, this applies a dead simple heuristic: only consider globals
|
|
|
|
/// used in minsize functions for merging.
|
|
|
|
/// FIXME: This could learn about optsize, and be used in the cost model.
|
2017-09-23 07:46:57 +08:00
|
|
|
bool OnlyOptimizeForSize = false;
|
2015-06-05 04:39:23 +08:00
|
|
|
|
2015-08-03 20:08:41 +08:00
|
|
|
/// Whether we should merge global variables that have external linkage.
|
2017-09-23 07:46:57 +08:00
|
|
|
bool MergeExternalGlobals = false;
|
2015-08-03 20:08:41 +08:00
|
|
|
|
2016-05-19 12:38:56 +08:00
|
|
|
bool IsMachO;
|
|
|
|
|
2010-07-25 05:52:08 +08:00
|
|
|
bool doMerge(SmallVectorImpl<GlobalVariable*> &Globals,
|
2013-01-07 20:31:25 +08:00
|
|
|
Module &M, bool isConst, unsigned AddrSpace) const;
|
2017-09-23 07:46:57 +08:00
|
|
|
|
2018-05-01 23:54:18 +08:00
|
|
|
/// Merge everything in \p Globals for which the corresponding bit
|
[GlobalMerge] Look at uses to create smaller global sets.
Instead of merging everything together, look at the users of
GlobalVariables, and try to group them by function, to create
sets of globals used "together".
Using that information, a less-aggressive alternative is to keep merging
everything together *except* globals that are only ever used alone, that
is, those for which it's clearly non-profitable to merge with others.
In my testing, grouping by Function is too aggressive, but grouping by
BasicBlock is too conservative. Anything in-between isn't trivially
available, so stick with Function grouping for now.
cl::opts are added for testing; both enabled by default.
A few of the testcases aren't testing the merging proper, but just
various edge cases when merging does occur. Update them to use the
previous grouping behavior. Also, one of the tests is unrelated to
GlobalMerge; change it accordingly.
While there, switch to r234666' flags rather than the brutal -O3.
Differential Revision: http://reviews.llvm.org/D8070
llvm-svn: 235249
2015-04-18 09:21:58 +08:00
|
|
|
/// in \p GlobalSet is set.
|
2015-08-22 06:19:06 +08:00
|
|
|
bool doMerge(const SmallVectorImpl<GlobalVariable *> &Globals,
|
[GlobalMerge] Look at uses to create smaller global sets.
Instead of merging everything together, look at the users of
GlobalVariables, and try to group them by function, to create
sets of globals used "together".
Using that information, a less-aggressive alternative is to keep merging
everything together *except* globals that are only ever used alone, that
is, those for which it's clearly non-profitable to merge with others.
In my testing, grouping by Function is too aggressive, but grouping by
BasicBlock is too conservative. Anything in-between isn't trivially
available, so stick with Function grouping for now.
cl::opts are added for testing; both enabled by default.
A few of the testcases aren't testing the merging proper, but just
various edge cases when merging does occur. Update them to use the
previous grouping behavior. Also, one of the tests is unrelated to
GlobalMerge; change it accordingly.
While there, switch to r234666' flags rather than the brutal -O3.
Differential Revision: http://reviews.llvm.org/D8070
llvm-svn: 235249
2015-04-18 09:21:58 +08:00
|
|
|
const BitVector &GlobalSet, Module &M, bool isConst,
|
|
|
|
unsigned AddrSpace) const;
|
2010-07-25 05:52:08 +08:00
|
|
|
|
2018-05-01 23:54:18 +08:00
|
|
|
/// Check if the given variable has been identified as must keep
|
2013-03-19 06:30:07 +08:00
|
|
|
/// \pre setMustKeepGlobalVariables must have been called on the Module that
|
|
|
|
/// contains GV
|
|
|
|
bool isMustKeepGlobalVariable(const GlobalVariable *GV) const {
|
|
|
|
return MustKeepGlobalVariables.count(GV);
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Collect every variables marked as "used" or used in a landing pad
|
|
|
|
/// instruction for this Module.
|
|
|
|
void setMustKeepGlobalVariables(Module &M);
|
|
|
|
|
|
|
|
/// Collect every variables marked as "used"
|
2018-07-26 06:03:35 +08:00
|
|
|
void collectUsedGlobalVariables(Module &M, StringRef Name);
|
2013-03-19 06:30:07 +08:00
|
|
|
|
2013-03-20 05:46:49 +08:00
|
|
|
/// Keep track of the GlobalVariable that must not be merged away
|
2013-03-19 06:30:07 +08:00
|
|
|
SmallPtrSet<const GlobalVariable *, 16> MustKeepGlobalVariables;
|
|
|
|
|
2010-07-25 05:52:08 +08:00
|
|
|
public:
|
|
|
|
static char ID; // Pass identification, replacement for typeid.
|
2017-09-23 07:46:57 +08:00
|
|
|
|
2016-05-19 12:38:56 +08:00
|
|
|
explicit GlobalMerge()
|
2017-09-23 07:46:57 +08:00
|
|
|
: FunctionPass(ID), MaxOffset(GlobalMergeMaxOffset) {
|
2016-05-19 12:38:56 +08:00
|
|
|
initializeGlobalMergePass(*PassRegistry::getPassRegistry());
|
|
|
|
}
|
|
|
|
|
|
|
|
explicit GlobalMerge(const TargetMachine *TM, unsigned MaximalOffset,
|
|
|
|
bool OnlyOptimizeForSize, bool MergeExternalGlobals)
|
2015-07-08 02:49:25 +08:00
|
|
|
: FunctionPass(ID), TM(TM), MaxOffset(MaximalOffset),
|
2015-08-03 20:08:41 +08:00
|
|
|
OnlyOptimizeForSize(OnlyOptimizeForSize),
|
|
|
|
MergeExternalGlobals(MergeExternalGlobals) {
|
2011-10-18 01:17:43 +08:00
|
|
|
initializeGlobalMergePass(*PassRegistry::getPassRegistry());
|
|
|
|
}
|
2010-07-25 05:52:08 +08:00
|
|
|
|
2014-03-05 17:10:37 +08:00
|
|
|
bool doInitialization(Module &M) override;
|
|
|
|
bool runOnFunction(Function &F) override;
|
|
|
|
bool doFinalization(Module &M) override;
|
2010-07-25 05:52:08 +08:00
|
|
|
|
2016-10-01 10:56:57 +08:00
|
|
|
StringRef getPassName() const override { return "Merge internal globals"; }
|
2010-07-25 05:52:08 +08:00
|
|
|
|
2014-03-05 17:10:37 +08:00
|
|
|
void getAnalysisUsage(AnalysisUsage &AU) const override {
|
2010-07-25 05:52:08 +08:00
|
|
|
AU.setPreservesCFG();
|
|
|
|
FunctionPass::getAnalysisUsage(AU);
|
|
|
|
}
|
|
|
|
};
|
2017-09-23 07:46:57 +08:00
|
|
|
|
2010-07-25 05:52:08 +08:00
|
|
|
} // end anonymous namespace
|
|
|
|
|
2011-10-18 01:17:43 +08:00
|
|
|
char GlobalMerge::ID = 0;
|
2017-09-23 07:46:57 +08:00
|
|
|
|
2017-05-26 05:26:32 +08:00
|
|
|
INITIALIZE_PASS(GlobalMerge, DEBUG_TYPE, "Merge global variables", false, false)
|
2010-07-25 05:52:08 +08:00
|
|
|
|
2011-10-18 01:17:43 +08:00
|
|
|
bool GlobalMerge::doMerge(SmallVectorImpl<GlobalVariable*> &Globals,
|
2013-01-07 20:31:25 +08:00
|
|
|
Module &M, bool isConst, unsigned AddrSpace) const {
|
2015-07-08 02:49:25 +08:00
|
|
|
auto &DL = M.getDataLayout();
|
2010-07-25 05:52:08 +08:00
|
|
|
// FIXME: Find better heuristics
|
2019-04-23 22:51:27 +08:00
|
|
|
llvm::stable_sort(
|
|
|
|
Globals, [&DL](const GlobalVariable *GV1, const GlobalVariable *GV2) {
|
|
|
|
return DL.getTypeAllocSize(GV1->getValueType()) <
|
|
|
|
DL.getTypeAllocSize(GV2->getValueType());
|
|
|
|
});
|
2010-07-25 05:52:08 +08:00
|
|
|
|
[GlobalMerge] Look at uses to create smaller global sets.
Instead of merging everything together, look at the users of
GlobalVariables, and try to group them by function, to create
sets of globals used "together".
Using that information, a less-aggressive alternative is to keep merging
everything together *except* globals that are only ever used alone, that
is, those for which it's clearly non-profitable to merge with others.
In my testing, grouping by Function is too aggressive, but grouping by
BasicBlock is too conservative. Anything in-between isn't trivially
available, so stick with Function grouping for now.
cl::opts are added for testing; both enabled by default.
A few of the testcases aren't testing the merging proper, but just
various edge cases when merging does occur. Update them to use the
previous grouping behavior. Also, one of the tests is unrelated to
GlobalMerge; change it accordingly.
While there, switch to r234666' flags rather than the brutal -O3.
Differential Revision: http://reviews.llvm.org/D8070
llvm-svn: 235249
2015-04-18 09:21:58 +08:00
|
|
|
// If we want to just blindly group all globals together, do so.
|
|
|
|
if (!GlobalMergeGroupByUse) {
|
|
|
|
BitVector AllGlobals(Globals.size());
|
|
|
|
AllGlobals.set();
|
|
|
|
return doMerge(Globals, AllGlobals, M, isConst, AddrSpace);
|
|
|
|
}
|
|
|
|
|
|
|
|
// If we want to be smarter, look at all uses of each global, to try to
|
|
|
|
// discover all sets of globals used together, and how many times each of
|
2015-08-09 02:27:36 +08:00
|
|
|
// these sets occurred.
|
[GlobalMerge] Look at uses to create smaller global sets.
Instead of merging everything together, look at the users of
GlobalVariables, and try to group them by function, to create
sets of globals used "together".
Using that information, a less-aggressive alternative is to keep merging
everything together *except* globals that are only ever used alone, that
is, those for which it's clearly non-profitable to merge with others.
In my testing, grouping by Function is too aggressive, but grouping by
BasicBlock is too conservative. Anything in-between isn't trivially
available, so stick with Function grouping for now.
cl::opts are added for testing; both enabled by default.
A few of the testcases aren't testing the merging proper, but just
various edge cases when merging does occur. Update them to use the
previous grouping behavior. Also, one of the tests is unrelated to
GlobalMerge; change it accordingly.
While there, switch to r234666' flags rather than the brutal -O3.
Differential Revision: http://reviews.llvm.org/D8070
llvm-svn: 235249
2015-04-18 09:21:58 +08:00
|
|
|
//
|
|
|
|
// Keep this reasonably efficient, by having an append-only list of all sets
|
|
|
|
// discovered so far (UsedGlobalSet), and mapping each "together-ness" unit of
|
|
|
|
// code (currently, a Function) to the set of globals seen so far that are
|
|
|
|
// used together in that unit (GlobalUsesByFunction).
|
|
|
|
//
|
2018-04-27 01:56:50 +08:00
|
|
|
// When we look at the Nth global, we know that any new set is either:
|
[GlobalMerge] Look at uses to create smaller global sets.
Instead of merging everything together, look at the users of
GlobalVariables, and try to group them by function, to create
sets of globals used "together".
Using that information, a less-aggressive alternative is to keep merging
everything together *except* globals that are only ever used alone, that
is, those for which it's clearly non-profitable to merge with others.
In my testing, grouping by Function is too aggressive, but grouping by
BasicBlock is too conservative. Anything in-between isn't trivially
available, so stick with Function grouping for now.
cl::opts are added for testing; both enabled by default.
A few of the testcases aren't testing the merging proper, but just
various edge cases when merging does occur. Update them to use the
previous grouping behavior. Also, one of the tests is unrelated to
GlobalMerge; change it accordingly.
While there, switch to r234666' flags rather than the brutal -O3.
Differential Revision: http://reviews.llvm.org/D8070
llvm-svn: 235249
2015-04-18 09:21:58 +08:00
|
|
|
// - the singleton set {N}, containing this global only, or
|
|
|
|
// - the union of {N} and a previously-discovered set, containing some
|
|
|
|
// combination of the previous N-1 globals.
|
|
|
|
// Using that knowledge, when looking at the Nth global, we can keep:
|
|
|
|
// - a reference to the singleton set {N} (CurGVOnlySetIdx)
|
|
|
|
// - a list mapping each previous set to its union with {N} (EncounteredUGS),
|
|
|
|
// if it actually occurs.
|
|
|
|
|
|
|
|
// We keep track of the sets of globals used together "close enough".
|
|
|
|
struct UsedGlobalSet {
|
|
|
|
BitVector Globals;
|
2017-09-23 07:46:57 +08:00
|
|
|
unsigned UsageCount = 1;
|
|
|
|
|
|
|
|
UsedGlobalSet(size_t Size) : Globals(Size) {}
|
[GlobalMerge] Look at uses to create smaller global sets.
Instead of merging everything together, look at the users of
GlobalVariables, and try to group them by function, to create
sets of globals used "together".
Using that information, a less-aggressive alternative is to keep merging
everything together *except* globals that are only ever used alone, that
is, those for which it's clearly non-profitable to merge with others.
In my testing, grouping by Function is too aggressive, but grouping by
BasicBlock is too conservative. Anything in-between isn't trivially
available, so stick with Function grouping for now.
cl::opts are added for testing; both enabled by default.
A few of the testcases aren't testing the merging proper, but just
various edge cases when merging does occur. Update them to use the
previous grouping behavior. Also, one of the tests is unrelated to
GlobalMerge; change it accordingly.
While there, switch to r234666' flags rather than the brutal -O3.
Differential Revision: http://reviews.llvm.org/D8070
llvm-svn: 235249
2015-04-18 09:21:58 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
// Each set is unique in UsedGlobalSets.
|
|
|
|
std::vector<UsedGlobalSet> UsedGlobalSets;
|
|
|
|
|
|
|
|
// Avoid repeating the create-global-set pattern.
|
|
|
|
auto CreateGlobalSet = [&]() -> UsedGlobalSet & {
|
|
|
|
UsedGlobalSets.emplace_back(Globals.size());
|
|
|
|
return UsedGlobalSets.back();
|
|
|
|
};
|
|
|
|
|
|
|
|
// The first set is the empty set.
|
|
|
|
CreateGlobalSet().UsageCount = 0;
|
|
|
|
|
|
|
|
// We define "close enough" to be "in the same function".
|
|
|
|
// FIXME: Grouping uses by function is way too aggressive, so we should have
|
|
|
|
// a better metric for distance between uses.
|
|
|
|
// The obvious alternative would be to group by BasicBlock, but that's in
|
|
|
|
// turn too conservative..
|
|
|
|
// Anything in between wouldn't be trivial to compute, so just stick with
|
|
|
|
// per-function grouping.
|
|
|
|
|
|
|
|
// The value type is an index into UsedGlobalSets.
|
|
|
|
// The default (0) conveniently points to the empty set.
|
|
|
|
DenseMap<Function *, size_t /*UsedGlobalSetIdx*/> GlobalUsesByFunction;
|
|
|
|
|
|
|
|
// Now, look at each merge-eligible global in turn.
|
|
|
|
|
|
|
|
// Keep track of the sets we already encountered to which we added the
|
|
|
|
// current global.
|
|
|
|
// Each element matches the same-index element in UsedGlobalSets.
|
|
|
|
// This lets us efficiently tell whether a set has already been expanded to
|
|
|
|
// include the current global.
|
|
|
|
std::vector<size_t> EncounteredUGS;
|
|
|
|
|
|
|
|
for (size_t GI = 0, GE = Globals.size(); GI != GE; ++GI) {
|
|
|
|
GlobalVariable *GV = Globals[GI];
|
|
|
|
|
|
|
|
// Reset the encountered sets for this global...
|
|
|
|
std::fill(EncounteredUGS.begin(), EncounteredUGS.end(), 0);
|
|
|
|
// ...and grow it in case we created new sets for the previous global.
|
|
|
|
EncounteredUGS.resize(UsedGlobalSets.size());
|
|
|
|
|
|
|
|
// We might need to create a set that only consists of the current global.
|
|
|
|
// Keep track of its index into UsedGlobalSets.
|
|
|
|
size_t CurGVOnlySetIdx = 0;
|
|
|
|
|
|
|
|
// For each global, look at all its Uses.
|
|
|
|
for (auto &U : GV->uses()) {
|
|
|
|
// This Use might be a ConstantExpr. We're interested in Instruction
|
|
|
|
// users, so look through ConstantExpr...
|
|
|
|
Use *UI, *UE;
|
|
|
|
if (ConstantExpr *CE = dyn_cast<ConstantExpr>(U.getUser())) {
|
2015-06-09 00:55:31 +08:00
|
|
|
if (CE->use_empty())
|
|
|
|
continue;
|
[GlobalMerge] Look at uses to create smaller global sets.
Instead of merging everything together, look at the users of
GlobalVariables, and try to group them by function, to create
sets of globals used "together".
Using that information, a less-aggressive alternative is to keep merging
everything together *except* globals that are only ever used alone, that
is, those for which it's clearly non-profitable to merge with others.
In my testing, grouping by Function is too aggressive, but grouping by
BasicBlock is too conservative. Anything in-between isn't trivially
available, so stick with Function grouping for now.
cl::opts are added for testing; both enabled by default.
A few of the testcases aren't testing the merging proper, but just
various edge cases when merging does occur. Update them to use the
previous grouping behavior. Also, one of the tests is unrelated to
GlobalMerge; change it accordingly.
While there, switch to r234666' flags rather than the brutal -O3.
Differential Revision: http://reviews.llvm.org/D8070
llvm-svn: 235249
2015-04-18 09:21:58 +08:00
|
|
|
UI = &*CE->use_begin();
|
|
|
|
UE = nullptr;
|
|
|
|
} else if (isa<Instruction>(U.getUser())) {
|
|
|
|
UI = &U;
|
|
|
|
UE = UI->getNext();
|
|
|
|
} else {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
// ...to iterate on all the instruction users of the global.
|
|
|
|
// Note that we iterate on Uses and not on Users to be able to getNext().
|
|
|
|
for (; UI != UE; UI = UI->getNext()) {
|
|
|
|
Instruction *I = dyn_cast<Instruction>(UI->getUser());
|
|
|
|
if (!I)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
Function *ParentFn = I->getParent()->getParent();
|
2015-06-05 04:39:23 +08:00
|
|
|
|
|
|
|
// If we're only optimizing for size, ignore non-minsize functions.
|
2019-04-05 06:40:06 +08:00
|
|
|
if (OnlyOptimizeForSize && !ParentFn->hasMinSize())
|
2015-06-05 04:39:23 +08:00
|
|
|
continue;
|
|
|
|
|
[GlobalMerge] Look at uses to create smaller global sets.
Instead of merging everything together, look at the users of
GlobalVariables, and try to group them by function, to create
sets of globals used "together".
Using that information, a less-aggressive alternative is to keep merging
everything together *except* globals that are only ever used alone, that
is, those for which it's clearly non-profitable to merge with others.
In my testing, grouping by Function is too aggressive, but grouping by
BasicBlock is too conservative. Anything in-between isn't trivially
available, so stick with Function grouping for now.
cl::opts are added for testing; both enabled by default.
A few of the testcases aren't testing the merging proper, but just
various edge cases when merging does occur. Update them to use the
previous grouping behavior. Also, one of the tests is unrelated to
GlobalMerge; change it accordingly.
While there, switch to r234666' flags rather than the brutal -O3.
Differential Revision: http://reviews.llvm.org/D8070
llvm-svn: 235249
2015-04-18 09:21:58 +08:00
|
|
|
size_t UGSIdx = GlobalUsesByFunction[ParentFn];
|
|
|
|
|
|
|
|
// If this is the first global the basic block uses, map it to the set
|
|
|
|
// consisting of this global only.
|
|
|
|
if (!UGSIdx) {
|
|
|
|
// If that set doesn't exist yet, create it.
|
|
|
|
if (!CurGVOnlySetIdx) {
|
|
|
|
CurGVOnlySetIdx = UsedGlobalSets.size();
|
|
|
|
CreateGlobalSet().Globals.set(GI);
|
|
|
|
} else {
|
|
|
|
++UsedGlobalSets[CurGVOnlySetIdx].UsageCount;
|
|
|
|
}
|
|
|
|
|
|
|
|
GlobalUsesByFunction[ParentFn] = CurGVOnlySetIdx;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If we already encountered this BB, just increment the counter.
|
|
|
|
if (UsedGlobalSets[UGSIdx].Globals.test(GI)) {
|
|
|
|
++UsedGlobalSets[UGSIdx].UsageCount;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If not, the previous set wasn't actually used in this function.
|
|
|
|
--UsedGlobalSets[UGSIdx].UsageCount;
|
|
|
|
|
|
|
|
// If we already expanded the previous set to include this global, just
|
|
|
|
// reuse that expanded set.
|
|
|
|
if (size_t ExpandedIdx = EncounteredUGS[UGSIdx]) {
|
|
|
|
++UsedGlobalSets[ExpandedIdx].UsageCount;
|
|
|
|
GlobalUsesByFunction[ParentFn] = ExpandedIdx;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If not, create a new set consisting of the union of the previous set
|
|
|
|
// and this global. Mark it as encountered, so we can reuse it later.
|
|
|
|
GlobalUsesByFunction[ParentFn] = EncounteredUGS[UGSIdx] =
|
|
|
|
UsedGlobalSets.size();
|
|
|
|
|
|
|
|
UsedGlobalSet &NewUGS = CreateGlobalSet();
|
|
|
|
NewUGS.Globals.set(GI);
|
|
|
|
NewUGS.Globals |= UsedGlobalSets[UGSIdx].Globals;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Now we found a bunch of sets of globals used together. We accumulated
|
|
|
|
// the number of times we encountered the sets (i.e., the number of blocks
|
|
|
|
// that use that exact set of globals).
|
|
|
|
//
|
|
|
|
// Multiply that by the size of the set to give us a crude profitability
|
|
|
|
// metric.
|
2019-04-23 22:51:27 +08:00
|
|
|
llvm::stable_sort(UsedGlobalSets,
|
|
|
|
[](const UsedGlobalSet &UGS1, const UsedGlobalSet &UGS2) {
|
|
|
|
return UGS1.Globals.count() * UGS1.UsageCount <
|
|
|
|
UGS2.Globals.count() * UGS2.UsageCount;
|
|
|
|
});
|
[GlobalMerge] Look at uses to create smaller global sets.
Instead of merging everything together, look at the users of
GlobalVariables, and try to group them by function, to create
sets of globals used "together".
Using that information, a less-aggressive alternative is to keep merging
everything together *except* globals that are only ever used alone, that
is, those for which it's clearly non-profitable to merge with others.
In my testing, grouping by Function is too aggressive, but grouping by
BasicBlock is too conservative. Anything in-between isn't trivially
available, so stick with Function grouping for now.
cl::opts are added for testing; both enabled by default.
A few of the testcases aren't testing the merging proper, but just
various edge cases when merging does occur. Update them to use the
previous grouping behavior. Also, one of the tests is unrelated to
GlobalMerge; change it accordingly.
While there, switch to r234666' flags rather than the brutal -O3.
Differential Revision: http://reviews.llvm.org/D8070
llvm-svn: 235249
2015-04-18 09:21:58 +08:00
|
|
|
|
|
|
|
// We can choose to merge all globals together, but ignore globals never used
|
|
|
|
// with another global. This catches the obviously non-profitable cases of
|
|
|
|
// having a single global, but is aggressive enough for any other case.
|
|
|
|
if (GlobalMergeIgnoreSingleUse) {
|
|
|
|
BitVector AllGlobals(Globals.size());
|
|
|
|
for (size_t i = 0, e = UsedGlobalSets.size(); i != e; ++i) {
|
|
|
|
const UsedGlobalSet &UGS = UsedGlobalSets[e - i - 1];
|
|
|
|
if (UGS.UsageCount == 0)
|
|
|
|
continue;
|
|
|
|
if (UGS.Globals.count() > 1)
|
|
|
|
AllGlobals |= UGS.Globals;
|
|
|
|
}
|
|
|
|
return doMerge(Globals, AllGlobals, M, isConst, AddrSpace);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Starting from the sets with the best (=biggest) profitability, find a
|
|
|
|
// good combination.
|
|
|
|
// The ideal (and expensive) solution can only be found by trying all
|
|
|
|
// combinations, looking for the one with the best profitability.
|
|
|
|
// Don't be smart about it, and just pick the first compatible combination,
|
|
|
|
// starting with the sets with the best profitability.
|
|
|
|
BitVector PickedGlobals(Globals.size());
|
|
|
|
bool Changed = false;
|
|
|
|
|
|
|
|
for (size_t i = 0, e = UsedGlobalSets.size(); i != e; ++i) {
|
|
|
|
const UsedGlobalSet &UGS = UsedGlobalSets[e - i - 1];
|
|
|
|
if (UGS.UsageCount == 0)
|
|
|
|
continue;
|
|
|
|
if (PickedGlobals.anyCommon(UGS.Globals))
|
|
|
|
continue;
|
|
|
|
PickedGlobals |= UGS.Globals;
|
|
|
|
// If the set only contains one global, there's no point in merging.
|
|
|
|
// Ignore the global for inclusion in other sets though, so keep it in
|
|
|
|
// PickedGlobals.
|
|
|
|
if (UGS.Globals.count() < 2)
|
|
|
|
continue;
|
|
|
|
Changed |= doMerge(Globals, UGS.Globals, M, isConst, AddrSpace);
|
|
|
|
}
|
|
|
|
|
|
|
|
return Changed;
|
|
|
|
}
|
|
|
|
|
2015-08-22 06:19:06 +08:00
|
|
|
bool GlobalMerge::doMerge(const SmallVectorImpl<GlobalVariable *> &Globals,
|
[GlobalMerge] Look at uses to create smaller global sets.
Instead of merging everything together, look at the users of
GlobalVariables, and try to group them by function, to create
sets of globals used "together".
Using that information, a less-aggressive alternative is to keep merging
everything together *except* globals that are only ever used alone, that
is, those for which it's clearly non-profitable to merge with others.
In my testing, grouping by Function is too aggressive, but grouping by
BasicBlock is too conservative. Anything in-between isn't trivially
available, so stick with Function grouping for now.
cl::opts are added for testing; both enabled by default.
A few of the testcases aren't testing the merging proper, but just
various edge cases when merging does occur. Update them to use the
previous grouping behavior. Also, one of the tests is unrelated to
GlobalMerge; change it accordingly.
While there, switch to r234666' flags rather than the brutal -O3.
Differential Revision: http://reviews.llvm.org/D8070
llvm-svn: 235249
2015-04-18 09:21:58 +08:00
|
|
|
const BitVector &GlobalSet, Module &M, bool isConst,
|
|
|
|
unsigned AddrSpace) const {
|
2015-08-22 06:19:06 +08:00
|
|
|
assert(Globals.size() > 1);
|
[GlobalMerge] Look at uses to create smaller global sets.
Instead of merging everything together, look at the users of
GlobalVariables, and try to group them by function, to create
sets of globals used "together".
Using that information, a less-aggressive alternative is to keep merging
everything together *except* globals that are only ever used alone, that
is, those for which it's clearly non-profitable to merge with others.
In my testing, grouping by Function is too aggressive, but grouping by
BasicBlock is too conservative. Anything in-between isn't trivially
available, so stick with Function grouping for now.
cl::opts are added for testing; both enabled by default.
A few of the testcases aren't testing the merging proper, but just
various edge cases when merging does occur. Update them to use the
previous grouping behavior. Also, one of the tests is unrelated to
GlobalMerge; change it accordingly.
While there, switch to r234666' flags rather than the brutal -O3.
Differential Revision: http://reviews.llvm.org/D8070
llvm-svn: 235249
2015-04-18 09:21:58 +08:00
|
|
|
|
2011-07-18 12:54:35 +08:00
|
|
|
Type *Int32Ty = Type::getInt32Ty(M.getContext());
|
2018-07-26 04:58:01 +08:00
|
|
|
Type *Int8Ty = Type::getInt8Ty(M.getContext());
|
2015-07-08 02:49:25 +08:00
|
|
|
auto &DL = M.getDataLayout();
|
2010-07-25 05:52:08 +08:00
|
|
|
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(dbgs() << " Trying to merge set, starts with #"
|
|
|
|
<< GlobalSet.find_first() << "\n");
|
[GlobalMerge] Look at uses to create smaller global sets.
Instead of merging everything together, look at the users of
GlobalVariables, and try to group them by function, to create
sets of globals used "together".
Using that information, a less-aggressive alternative is to keep merging
everything together *except* globals that are only ever used alone, that
is, those for which it's clearly non-profitable to merge with others.
In my testing, grouping by Function is too aggressive, but grouping by
BasicBlock is too conservative. Anything in-between isn't trivially
available, so stick with Function grouping for now.
cl::opts are added for testing; both enabled by default.
A few of the testcases aren't testing the merging proper, but just
various edge cases when merging does occur. Update them to use the
previous grouping behavior. Also, one of the tests is unrelated to
GlobalMerge; change it accordingly.
While there, switch to r234666' flags rather than the brutal -O3.
Differential Revision: http://reviews.llvm.org/D8070
llvm-svn: 235249
2015-04-18 09:21:58 +08:00
|
|
|
|
2018-05-20 02:00:02 +08:00
|
|
|
bool Changed = false;
|
[GlobalMerge] Look at uses to create smaller global sets.
Instead of merging everything together, look at the users of
GlobalVariables, and try to group them by function, to create
sets of globals used "together".
Using that information, a less-aggressive alternative is to keep merging
everything together *except* globals that are only ever used alone, that
is, those for which it's clearly non-profitable to merge with others.
In my testing, grouping by Function is too aggressive, but grouping by
BasicBlock is too conservative. Anything in-between isn't trivially
available, so stick with Function grouping for now.
cl::opts are added for testing; both enabled by default.
A few of the testcases aren't testing the merging proper, but just
various edge cases when merging does occur. Update them to use the
previous grouping behavior. Also, one of the tests is unrelated to
GlobalMerge; change it accordingly.
While there, switch to r234666' flags rather than the brutal -O3.
Differential Revision: http://reviews.llvm.org/D8070
llvm-svn: 235249
2015-04-18 09:21:58 +08:00
|
|
|
ssize_t i = GlobalSet.find_first();
|
|
|
|
while (i != -1) {
|
|
|
|
ssize_t j = 0;
|
2010-07-25 05:52:08 +08:00
|
|
|
uint64_t MergedSize = 0;
|
2011-07-12 22:06:48 +08:00
|
|
|
std::vector<Type*> Tys;
|
2010-07-25 05:52:08 +08:00
|
|
|
std::vector<Constant*> Inits;
|
2018-07-26 04:58:01 +08:00
|
|
|
std::vector<unsigned> StructIdxs;
|
2014-06-11 14:44:53 +08:00
|
|
|
|
2016-11-12 01:50:09 +08:00
|
|
|
bool HasExternal = false;
|
2016-11-12 06:09:25 +08:00
|
|
|
StringRef FirstExternalName;
|
2019-10-15 19:24:36 +08:00
|
|
|
Align MaxAlign;
|
2018-07-26 04:58:01 +08:00
|
|
|
unsigned CurIdx = 0;
|
[GlobalMerge] Look at uses to create smaller global sets.
Instead of merging everything together, look at the users of
GlobalVariables, and try to group them by function, to create
sets of globals used "together".
Using that information, a less-aggressive alternative is to keep merging
everything together *except* globals that are only ever used alone, that
is, those for which it's clearly non-profitable to merge with others.
In my testing, grouping by Function is too aggressive, but grouping by
BasicBlock is too conservative. Anything in-between isn't trivially
available, so stick with Function grouping for now.
cl::opts are added for testing; both enabled by default.
A few of the testcases aren't testing the merging proper, but just
various edge cases when merging does occur. Update them to use the
previous grouping behavior. Also, one of the tests is unrelated to
GlobalMerge; change it accordingly.
While there, switch to r234666' flags rather than the brutal -O3.
Differential Revision: http://reviews.llvm.org/D8070
llvm-svn: 235249
2015-04-18 09:21:58 +08:00
|
|
|
for (j = i; j != -1; j = GlobalSet.find_next(j)) {
|
2015-08-22 06:00:44 +08:00
|
|
|
Type *Ty = Globals[j]->getValueType();
|
2018-08-03 07:54:16 +08:00
|
|
|
|
2018-08-30 07:46:26 +08:00
|
|
|
// Make sure we use the same alignment AsmPrinter would use.
|
2019-10-15 19:24:36 +08:00
|
|
|
Align Alignment(DL.getPreferredAlignment(Globals[j]));
|
|
|
|
unsigned Padding = alignTo(MergedSize, Alignment) - MergedSize;
|
2018-07-26 04:58:01 +08:00
|
|
|
MergedSize += Padding;
|
2015-07-08 02:49:25 +08:00
|
|
|
MergedSize += DL.getTypeAllocSize(Ty);
|
2010-11-18 05:25:36 +08:00
|
|
|
if (MergedSize > MaxOffset) {
|
|
|
|
break;
|
|
|
|
}
|
2018-07-26 04:58:01 +08:00
|
|
|
if (Padding) {
|
|
|
|
Tys.push_back(ArrayType::get(Int8Ty, Padding));
|
|
|
|
Inits.push_back(ConstantAggregateZero::get(Tys.back()));
|
|
|
|
++CurIdx;
|
|
|
|
}
|
2010-07-25 05:52:08 +08:00
|
|
|
Tys.push_back(Ty);
|
|
|
|
Inits.push_back(Globals[j]->getInitializer());
|
2018-07-26 04:58:01 +08:00
|
|
|
StructIdxs.push_back(CurIdx++);
|
|
|
|
|
2019-10-15 19:24:36 +08:00
|
|
|
MaxAlign = std::max(MaxAlign, Alignment);
|
2016-11-12 01:50:09 +08:00
|
|
|
|
|
|
|
if (Globals[j]->hasExternalLinkage() && !HasExternal) {
|
|
|
|
HasExternal = true;
|
2016-11-12 06:09:25 +08:00
|
|
|
FirstExternalName = Globals[j]->getName();
|
2016-11-12 01:50:09 +08:00
|
|
|
}
|
2010-07-25 05:52:08 +08:00
|
|
|
}
|
|
|
|
|
2018-05-20 02:00:02 +08:00
|
|
|
// Exit early if there is only one global to merge.
|
|
|
|
if (Tys.size() < 2) {
|
|
|
|
i = j;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2016-11-12 01:50:09 +08:00
|
|
|
// If merged variables doesn't have external linkage, we needn't to expose
|
|
|
|
// the symbol after merging.
|
|
|
|
GlobalValue::LinkageTypes Linkage = HasExternal
|
|
|
|
? GlobalValue::ExternalLinkage
|
|
|
|
: GlobalValue::InternalLinkage;
|
2018-07-26 04:58:01 +08:00
|
|
|
// Use a packed struct so we can control alignment.
|
|
|
|
StructType *MergedTy = StructType::get(M.getContext(), Tys, true);
|
2010-09-06 05:18:45 +08:00
|
|
|
Constant *MergedInit = ConstantStruct::get(MergedTy, Inits);
|
2014-06-11 14:44:53 +08:00
|
|
|
|
2016-11-12 05:48:09 +08:00
|
|
|
// On Darwin external linkage needs to be preserved, otherwise
|
|
|
|
// dsymutil cannot preserve the debug info for the merged
|
|
|
|
// variables. If they have external linkage, use the symbol name
|
|
|
|
// of the first variable merged as the suffix of global symbol
|
|
|
|
// name. This avoids a link-time naming conflict for the
|
|
|
|
// _MergedGlobals symbols.
|
2016-11-12 01:50:09 +08:00
|
|
|
Twine MergedName =
|
|
|
|
(IsMachO && HasExternal)
|
2016-11-12 06:09:25 +08:00
|
|
|
? "_MergedGlobals_" + FirstExternalName
|
2016-11-12 01:50:09 +08:00
|
|
|
: "_MergedGlobals";
|
|
|
|
auto MergedLinkage = IsMachO ? Linkage : GlobalValue::PrivateLinkage;
|
|
|
|
auto *MergedGV = new GlobalVariable(
|
|
|
|
M, MergedTy, isConst, MergedLinkage, MergedInit, MergedName, nullptr,
|
|
|
|
GlobalVariable::NotThreadLocal, AddrSpace);
|
2014-06-11 14:44:53 +08:00
|
|
|
|
2018-07-26 04:58:01 +08:00
|
|
|
MergedGV->setAlignment(MaxAlign);
|
2018-08-03 07:54:16 +08:00
|
|
|
MergedGV->setSection(Globals[i]->getSection());
|
2016-09-13 09:12:59 +08:00
|
|
|
|
2018-07-26 04:58:01 +08:00
|
|
|
const StructLayout *MergedLayout = DL.getStructLayout(MergedTy);
|
2015-09-15 04:29:26 +08:00
|
|
|
for (ssize_t k = i, idx = 0; k != j; k = GlobalSet.find_next(k), ++idx) {
|
2014-06-11 14:44:53 +08:00
|
|
|
GlobalValue::LinkageTypes Linkage = Globals[k]->getLinkage();
|
2020-01-29 03:23:46 +08:00
|
|
|
std::string Name(Globals[k]->getName());
|
2020-01-29 04:43:07 +08:00
|
|
|
GlobalValue::VisibilityTypes Visibility = Globals[k]->getVisibility();
|
2018-02-13 05:14:21 +08:00
|
|
|
GlobalValue::DLLStorageClassTypes DLLStorage =
|
|
|
|
Globals[k]->getDLLStorageClass();
|
2014-06-11 14:44:53 +08:00
|
|
|
|
2016-09-13 09:12:59 +08:00
|
|
|
// Copy metadata while adjusting any debug info metadata by the original
|
|
|
|
// global's offset within the merged global.
|
2018-07-26 04:58:01 +08:00
|
|
|
MergedGV->copyMetadata(Globals[k],
|
|
|
|
MergedLayout->getElementOffset(StructIdxs[idx]));
|
2016-09-13 09:12:59 +08:00
|
|
|
|
2010-09-06 05:18:45 +08:00
|
|
|
Constant *Idx[2] = {
|
2018-07-26 04:58:01 +08:00
|
|
|
ConstantInt::get(Int32Ty, 0),
|
|
|
|
ConstantInt::get(Int32Ty, StructIdxs[idx]),
|
2010-09-06 05:18:45 +08:00
|
|
|
};
|
2015-04-03 02:55:32 +08:00
|
|
|
Constant *GEP =
|
|
|
|
ConstantExpr::getInBoundsGetElementPtr(MergedTy, MergedGV, Idx);
|
2010-07-25 05:52:08 +08:00
|
|
|
Globals[k]->replaceAllUsesWith(GEP);
|
|
|
|
Globals[k]->eraseFromParent();
|
2014-06-11 14:44:53 +08:00
|
|
|
|
2015-08-12 21:36:48 +08:00
|
|
|
// When the linkage is not internal we must emit an alias for the original
|
|
|
|
// variable name as it may be accessed from another object. On non-Mach-O
|
|
|
|
// we can also emit an alias for internal linkage as it's safe to do so.
|
|
|
|
// It's not safe on Mach-O as the alias (and thus the portion of the
|
|
|
|
// MergedGlobals variable) may be dead stripped at link time.
|
2016-05-19 12:38:56 +08:00
|
|
|
if (Linkage != GlobalValue::InternalLinkage || !IsMachO) {
|
2018-07-26 04:58:01 +08:00
|
|
|
GlobalAlias *GA = GlobalAlias::create(Tys[StructIdxs[idx]], AddrSpace,
|
|
|
|
Linkage, Name, GEP, &M);
|
2020-01-29 04:43:07 +08:00
|
|
|
GA->setVisibility(Visibility);
|
2018-02-13 05:14:21 +08:00
|
|
|
GA->setDLLStorageClass(DLLStorage);
|
2015-08-12 21:36:48 +08:00
|
|
|
}
|
2014-06-11 14:44:53 +08:00
|
|
|
|
2011-10-18 01:17:43 +08:00
|
|
|
NumMerged++;
|
2010-07-25 05:52:08 +08:00
|
|
|
}
|
2018-05-20 02:00:02 +08:00
|
|
|
Changed = true;
|
2010-07-25 05:52:08 +08:00
|
|
|
i = j;
|
|
|
|
}
|
|
|
|
|
2018-05-20 02:00:02 +08:00
|
|
|
return Changed;
|
2010-07-25 05:52:08 +08:00
|
|
|
}
|
|
|
|
|
2018-07-26 06:03:35 +08:00
|
|
|
void GlobalMerge::collectUsedGlobalVariables(Module &M, StringRef Name) {
|
2013-03-19 06:30:07 +08:00
|
|
|
// Extract global variables from llvm.used array
|
2018-07-26 06:03:35 +08:00
|
|
|
const GlobalVariable *GV = M.getGlobalVariable(Name);
|
2013-03-19 06:30:07 +08:00
|
|
|
if (!GV || !GV->hasInitializer()) return;
|
|
|
|
|
|
|
|
// Should be an array of 'i8*'.
|
2013-04-22 22:58:02 +08:00
|
|
|
const ConstantArray *InitList = cast<ConstantArray>(GV->getInitializer());
|
|
|
|
|
2013-03-19 06:30:07 +08:00
|
|
|
for (unsigned i = 0, e = InitList->getNumOperands(); i != e; ++i)
|
|
|
|
if (const GlobalVariable *G =
|
|
|
|
dyn_cast<GlobalVariable>(InitList->getOperand(i)->stripPointerCasts()))
|
|
|
|
MustKeepGlobalVariables.insert(G);
|
|
|
|
}
|
|
|
|
|
|
|
|
void GlobalMerge::setMustKeepGlobalVariables(Module &M) {
|
2018-07-26 06:03:35 +08:00
|
|
|
collectUsedGlobalVariables(M, "llvm.used");
|
|
|
|
collectUsedGlobalVariables(M, "llvm.compiler.used");
|
2013-03-19 06:30:07 +08:00
|
|
|
|
2016-10-20 03:56:22 +08:00
|
|
|
for (Function &F : M) {
|
|
|
|
for (BasicBlock &BB : F) {
|
|
|
|
Instruction *Pad = BB.getFirstNonPHI();
|
|
|
|
if (!Pad->isEHPad())
|
|
|
|
continue;
|
|
|
|
|
|
|
|
// Keep globals used by landingpads and catchpads.
|
|
|
|
for (const Use &U : Pad->operands()) {
|
2013-03-19 06:30:07 +08:00
|
|
|
if (const GlobalVariable *GV =
|
2016-10-20 03:56:22 +08:00
|
|
|
dyn_cast<GlobalVariable>(U->stripPointerCasts()))
|
2013-03-19 06:30:07 +08:00
|
|
|
MustKeepGlobalVariables.insert(GV);
|
2016-10-20 03:56:22 +08:00
|
|
|
}
|
2013-03-19 06:30:07 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2010-07-25 05:52:08 +08:00
|
|
|
|
2011-10-18 01:17:43 +08:00
|
|
|
bool GlobalMerge::doInitialization(Module &M) {
|
2014-02-18 19:17:29 +08:00
|
|
|
if (!EnableGlobalMerge)
|
|
|
|
return false;
|
|
|
|
|
2016-05-19 12:38:56 +08:00
|
|
|
IsMachO = Triple(M.getTargetTriple()).isOSBinFormatMachO();
|
|
|
|
|
2015-07-08 02:49:25 +08:00
|
|
|
auto &DL = M.getDataLayout();
|
2018-08-03 07:54:16 +08:00
|
|
|
DenseMap<std::pair<unsigned, StringRef>, SmallVector<GlobalVariable *, 16>>
|
|
|
|
Globals, ConstGlobals, BSSGlobals;
|
2010-07-25 05:52:08 +08:00
|
|
|
bool Changed = false;
|
2013-03-19 06:30:07 +08:00
|
|
|
setMustKeepGlobalVariables(M);
|
2010-07-25 05:52:08 +08:00
|
|
|
|
|
|
|
// Grab all non-const globals.
|
2015-10-10 02:57:47 +08:00
|
|
|
for (auto &GV : M.globals()) {
|
2014-06-11 14:44:53 +08:00
|
|
|
// Merge is safe for "normal" internal or external globals only
|
2018-08-03 07:54:16 +08:00
|
|
|
if (GV.isDeclaration() || GV.isThreadLocal() || GV.hasImplicitSection())
|
2014-06-11 14:44:53 +08:00
|
|
|
continue;
|
2017-06-02 18:24:14 +08:00
|
|
|
|
|
|
|
// It's not safe to merge globals that may be preempted
|
|
|
|
if (TM && !TM->shouldAssumeDSOLocal(M, &GV))
|
|
|
|
continue;
|
2014-06-11 14:44:53 +08:00
|
|
|
|
2015-10-10 02:57:47 +08:00
|
|
|
if (!(MergeExternalGlobals && GV.hasExternalLinkage()) &&
|
|
|
|
!GV.hasInternalLinkage())
|
2010-07-25 05:52:08 +08:00
|
|
|
continue;
|
|
|
|
|
2015-10-10 02:57:47 +08:00
|
|
|
PointerType *PT = dyn_cast<PointerType>(GV.getType());
|
2013-01-07 20:31:25 +08:00
|
|
|
assert(PT && "Global variable is not a pointer!");
|
|
|
|
|
|
|
|
unsigned AddressSpace = PT->getAddressSpace();
|
2018-08-03 07:54:16 +08:00
|
|
|
StringRef Section = GV.getSection();
|
2013-01-07 20:31:25 +08:00
|
|
|
|
2010-07-27 02:45:39 +08:00
|
|
|
// Ignore all 'special' globals.
|
2015-10-10 02:57:47 +08:00
|
|
|
if (GV.getName().startswith("llvm.") ||
|
|
|
|
GV.getName().startswith(".llvm."))
|
2010-07-27 02:45:39 +08:00
|
|
|
continue;
|
|
|
|
|
2013-03-19 06:30:07 +08:00
|
|
|
// Ignore all "required" globals:
|
2015-10-10 02:57:47 +08:00
|
|
|
if (isMustKeepGlobalVariable(&GV))
|
2013-03-19 06:30:07 +08:00
|
|
|
continue;
|
|
|
|
|
2018-07-26 04:58:01 +08:00
|
|
|
Type *Ty = GV.getValueType();
|
2015-07-08 02:49:25 +08:00
|
|
|
if (DL.getTypeAllocSize(Ty) < MaxOffset) {
|
2016-05-19 12:38:56 +08:00
|
|
|
if (TM &&
|
2018-08-30 08:49:50 +08:00
|
|
|
TargetLoweringObjectFile::getKindForGlobal(&GV, *TM).isBSS())
|
2018-08-03 07:54:16 +08:00
|
|
|
BSSGlobals[{AddressSpace, Section}].push_back(&GV);
|
2015-10-10 02:57:47 +08:00
|
|
|
else if (GV.isConstant())
|
2018-08-03 07:54:16 +08:00
|
|
|
ConstGlobals[{AddressSpace, Section}].push_back(&GV);
|
2010-07-25 05:52:08 +08:00
|
|
|
else
|
2018-08-03 07:54:16 +08:00
|
|
|
Globals[{AddressSpace, Section}].push_back(&GV);
|
2010-07-25 05:52:08 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-08-22 06:19:06 +08:00
|
|
|
for (auto &P : Globals)
|
|
|
|
if (P.second.size() > 1)
|
2018-08-03 07:54:16 +08:00
|
|
|
Changed |= doMerge(P.second, M, false, P.first.first);
|
2015-08-22 06:19:06 +08:00
|
|
|
|
|
|
|
for (auto &P : BSSGlobals)
|
|
|
|
if (P.second.size() > 1)
|
2018-08-03 07:54:16 +08:00
|
|
|
Changed |= doMerge(P.second, M, false, P.first.first);
|
2015-08-22 06:19:06 +08:00
|
|
|
|
2015-08-26 01:01:36 +08:00
|
|
|
if (EnableGlobalMergeOnConst)
|
|
|
|
for (auto &P : ConstGlobals)
|
|
|
|
if (P.second.size() > 1)
|
2018-08-03 07:54:16 +08:00
|
|
|
Changed |= doMerge(P.second, M, true, P.first.first);
|
2010-07-25 05:52:08 +08:00
|
|
|
|
|
|
|
return Changed;
|
|
|
|
}
|
|
|
|
|
2011-10-18 01:17:43 +08:00
|
|
|
bool GlobalMerge::runOnFunction(Function &F) {
|
2010-07-25 05:52:08 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2013-03-20 05:46:49 +08:00
|
|
|
bool GlobalMerge::doFinalization(Module &M) {
|
|
|
|
MustKeepGlobalVariables.clear();
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2015-06-05 04:39:23 +08:00
|
|
|
Pass *llvm::createGlobalMergePass(const TargetMachine *TM, unsigned Offset,
|
2015-08-03 20:08:41 +08:00
|
|
|
bool OnlyOptimizeForSize,
|
|
|
|
bool MergeExternalByDefault) {
|
|
|
|
bool MergeExternal = (EnableGlobalMergeOnExternal == cl::BOU_UNSET) ?
|
|
|
|
MergeExternalByDefault : (EnableGlobalMergeOnExternal == cl::BOU_TRUE);
|
|
|
|
return new GlobalMerge(TM, Offset, OnlyOptimizeForSize, MergeExternal);
|
2010-07-25 05:52:08 +08:00
|
|
|
}
|