2014-07-19 03:13:09 +08:00
|
|
|
//===- MergedLoadStoreMotion.cpp - merge and hoist/sink load/stores -------===//
|
|
|
|
//
|
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
|
2014-07-19 03:13:09 +08:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
//! \file
|
2018-05-01 23:54:18 +08:00
|
|
|
//! This pass performs merges of loads and stores on both sides of a
|
2014-07-19 03:13:09 +08:00
|
|
|
// diamond (hammock). It hoists the loads and sinks the stores.
|
|
|
|
//
|
|
|
|
// The algorithm iteratively hoists two loads to the same address out of a
|
|
|
|
// diamond (hammock) and merges them into a single load in the header. Similar
|
|
|
|
// it sinks and merges two stores to the tail block (footer). The algorithm
|
|
|
|
// iterates over the instructions of one side of the diamond and attempts to
|
[MergedLoadStoreMotion] Sink stores to BB with more than 2 predecessors
If we have:
bb5:
br i1 %arg3, label %bb6, label %bb7
bb6:
%tmp = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp, align 4
br label %bb9
bb7:
%tmp8 = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp8, align 4
br label %bb9
bb9: ; preds = %bb4, %bb6, %bb7
...
We can't sink stores directly into bb9.
This patch creates new BB that is successor of %bb6 and %bb7
and sinks stores into that block.
SplitFooterBB is the parameter to the pass that controls
that behavior.
Change-Id: I7fdf50a772b84633e4b1b860e905bf7e3e29940f
Differential: https://reviews.llvm.org/D66234
llvm-svn: 371089
2019-09-06 01:00:32 +08:00
|
|
|
// find a matching load/store on the other side. New tail/footer block may be
|
|
|
|
// insterted if the tail/footer block has more predecessors (not only the two
|
|
|
|
// predecessors that are forming the diamond). It hoists / sinks when it thinks
|
|
|
|
// it safe to do so. This optimization helps with eg. hiding load latencies,
|
|
|
|
// triggering if-conversion, and reducing static code size.
|
2014-07-19 03:13:09 +08:00
|
|
|
//
|
Remove the load hoisting code of MLSM, it is completely subsumed by GVNHoist
Summary:
GVNHoist performs all the optimizations that MLSM does to loads, in a
more general way, and in a faster time bound (MLSM is N^3 in most
cases, N^4 in a few edge cases).
This disables the load portion.
Note that the way ld_hoist_st_sink.ll is written makes one think that
the loads should be moved to the while.preheader block, but
1. Neither MLSM nor GVNHoist do it (they both move them to identical places).
2. MLSM couldn't possibly do it anyway, as the while.preheader block
is not the head of the diamond, while.body is. (GVNHoist could do it
if it was legal).
3. At a glance, it's not legal anyway because the in-loop load
conflict with the in-loop store, so the loads must stay in-loop.
I am happy to update the test to use update_test_checks so that
checking is tighter, just was going to do it as a followup.
Note that i can find no particular benefit to the store portion on any
real testcase/benchmark i have (even size-wise). If we really still
want it, i am happy to commit to writing a targeted store sinker, just
taking the code from the MemorySSA port of MergedLoadStoreMotion
(which is N^2 worst case, and N most of the time).
We can do what it does in a much better time bound.
We also should be both hoisting and sinking stores, not just sinking
them, anyway, since whether we should hoist or sink to merge depends
basically on luck of the draw of where the blockers are placed.
Nonetheless, i have left it alone for now.
Reviewers: chandlerc, davide
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D29079
llvm-svn: 292971
2017-01-25 03:55:36 +08:00
|
|
|
// NOTE: This code no longer performs load hoisting, it is subsumed by GVNHoist.
|
|
|
|
//
|
2014-07-19 03:13:09 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
//
|
|
|
|
// Example:
|
|
|
|
// Diamond shaped code before merge:
|
|
|
|
//
|
|
|
|
// header:
|
|
|
|
// br %cond, label %if.then, label %if.else
|
2014-08-08 07:19:55 +08:00
|
|
|
// + +
|
|
|
|
// + +
|
|
|
|
// + +
|
2014-07-19 03:13:09 +08:00
|
|
|
// if.then: if.else:
|
|
|
|
// %lt = load %addr_l %le = load %addr_l
|
|
|
|
// <use %lt> <use %le>
|
|
|
|
// <...> <...>
|
|
|
|
// store %st, %addr_s store %se, %addr_s
|
|
|
|
// br label %if.end br label %if.end
|
2014-08-08 07:19:55 +08:00
|
|
|
// + +
|
|
|
|
// + +
|
|
|
|
// + +
|
2014-07-19 03:13:09 +08:00
|
|
|
// if.end ("footer"):
|
|
|
|
// <...>
|
|
|
|
//
|
|
|
|
// Diamond shaped code after merge:
|
|
|
|
//
|
|
|
|
// header:
|
|
|
|
// %l = load %addr_l
|
|
|
|
// br %cond, label %if.then, label %if.else
|
2014-08-08 07:19:55 +08:00
|
|
|
// + +
|
|
|
|
// + +
|
|
|
|
// + +
|
2014-07-19 03:13:09 +08:00
|
|
|
// if.then: if.else:
|
|
|
|
// <use %l> <use %l>
|
|
|
|
// <...> <...>
|
|
|
|
// br label %if.end br label %if.end
|
2014-08-08 07:19:55 +08:00
|
|
|
// + +
|
|
|
|
// + +
|
|
|
|
// + +
|
2014-07-19 03:13:09 +08:00
|
|
|
// if.end ("footer"):
|
|
|
|
// %s.sink = phi [%st, if.then], [%se, if.else]
|
|
|
|
// <...>
|
|
|
|
// store %s.sink, %addr_s
|
|
|
|
// <...>
|
|
|
|
//
|
|
|
|
//
|
|
|
|
//===----------------------- TODO -----------------------------------------===//
|
|
|
|
//
|
|
|
|
// 1) Generalize to regions other than diamonds
|
|
|
|
// 2) Be more aggressive merging memory operations
|
|
|
|
// Note that both changes require register pressure control
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2016-06-18 03:10:09 +08:00
|
|
|
#include "llvm/Transforms/Scalar/MergedLoadStoreMotion.h"
|
2014-07-19 03:13:09 +08:00
|
|
|
#include "llvm/ADT/Statistic.h"
|
|
|
|
#include "llvm/Analysis/AliasAnalysis.h"
|
|
|
|
#include "llvm/Analysis/CFG.h"
|
[PM/AA] Rebuild LLVM's alias analysis infrastructure in a way compatible
with the new pass manager, and no longer relying on analysis groups.
This builds essentially a ground-up new AA infrastructure stack for
LLVM. The core ideas are the same that are used throughout the new pass
manager: type erased polymorphism and direct composition. The design is
as follows:
- FunctionAAResults is a type-erasing alias analysis results aggregation
interface to walk a single query across a range of results from
different alias analyses. Currently this is function-specific as we
always assume that aliasing queries are *within* a function.
- AAResultBase is a CRTP utility providing stub implementations of
various parts of the alias analysis result concept, notably in several
cases in terms of other more general parts of the interface. This can
be used to implement only a narrow part of the interface rather than
the entire interface. This isn't really ideal, this logic should be
hoisted into FunctionAAResults as currently it will cause
a significant amount of redundant work, but it faithfully models the
behavior of the prior infrastructure.
- All the alias analysis passes are ported to be wrapper passes for the
legacy PM and new-style analysis passes for the new PM with a shared
result object. In some cases (most notably CFL), this is an extremely
naive approach that we should revisit when we can specialize for the
new pass manager.
- BasicAA has been restructured to reflect that it is much more
fundamentally a function analysis because it uses dominator trees and
loop info that need to be constructed for each function.
All of the references to getting alias analysis results have been
updated to use the new aggregation interface. All the preservation and
other pass management code has been updated accordingly.
The way the FunctionAAResultsWrapperPass works is to detect the
available alias analyses when run, and add them to the results object.
This means that we should be able to continue to respect when various
passes are added to the pipeline, for example adding CFL or adding TBAA
passes should just cause their results to be available and to get folded
into this. The exception to this rule is BasicAA which really needs to
be a function pass due to using dominator trees and loop info. As
a consequence, the FunctionAAResultsWrapperPass directly depends on
BasicAA and always includes it in the aggregation.
This has significant implications for preserving analyses. Generally,
most passes shouldn't bother preserving FunctionAAResultsWrapperPass
because rebuilding the results just updates the set of known AA passes.
The exception to this rule are LoopPass instances which need to preserve
all the function analyses that the loop pass manager will end up
needing. This means preserving both BasicAAWrapperPass and the
aggregating FunctionAAResultsWrapperPass.
Now, when preserving an alias analysis, you do so by directly preserving
that analysis. This is only necessary for non-immutable-pass-provided
alias analyses though, and there are only three of interest: BasicAA,
GlobalsAA (formerly GlobalsModRef), and SCEVAA. Usually BasicAA is
preserved when needed because it (like DominatorTree and LoopInfo) is
marked as a CFG-only pass. I've expanded GlobalsAA into the preserved
set everywhere we previously were preserving all of AliasAnalysis, and
I've added SCEVAA in the intersection of that with where we preserve
SCEV itself.
One significant challenge to all of this is that the CGSCC passes were
actually using the alias analysis implementations by taking advantage of
a pretty amazing set of loop holes in the old pass manager's analysis
management code which allowed analysis groups to slide through in many
cases. Moving away from analysis groups makes this problem much more
obvious. To fix it, I've leveraged the flexibility the design of the new
PM components provides to just directly construct the relevant alias
analyses for the relevant functions in the IPO passes that need them.
This is a bit hacky, but should go away with the new pass manager, and
is already in many ways cleaner than the prior state.
Another significant challenge is that various facilities of the old
alias analysis infrastructure just don't fit any more. The most
significant of these is the alias analysis 'counter' pass. That pass
relied on the ability to snoop on AA queries at different points in the
analysis group chain. Instead, I'm planning to build printing
functionality directly into the aggregation layer. I've not included
that in this patch merely to keep it smaller.
Note that all of this needs a nearly complete rewrite of the AA
documentation. I'm planning to do that, but I'd like to make sure the
new design settles, and to flesh out a bit more of what it looks like in
the new pass manager first.
Differential Revision: http://reviews.llvm.org/D12080
llvm-svn: 247167
2015-09-10 01:55:00 +08:00
|
|
|
#include "llvm/Analysis/GlobalsModRef.h"
|
2014-07-19 03:13:09 +08:00
|
|
|
#include "llvm/Analysis/Loads.h"
|
2016-06-12 10:11:20 +08:00
|
|
|
#include "llvm/Analysis/ValueTracking.h"
|
2014-07-19 03:13:09 +08:00
|
|
|
#include "llvm/IR/Metadata.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"
|
2014-07-19 03:13:09 +08:00
|
|
|
#include "llvm/Support/Debug.h"
|
2015-03-24 02:45:56 +08:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2016-04-18 17:17:29 +08:00
|
|
|
#include "llvm/Transforms/Scalar.h"
|
2014-07-19 03:13:09 +08:00
|
|
|
#include "llvm/Transforms/Utils/BasicBlockUtils.h"
|
2015-10-07 07:24:35 +08:00
|
|
|
|
2014-07-19 03:13:09 +08:00
|
|
|
using namespace llvm;
|
|
|
|
|
|
|
|
#define DEBUG_TYPE "mldst-motion"
|
|
|
|
|
2016-07-10 19:28:51 +08:00
|
|
|
namespace {
|
2014-07-19 03:13:09 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// MergedLoadStoreMotion Pass
|
|
|
|
//===----------------------------------------------------------------------===//
|
2016-06-18 03:10:09 +08:00
|
|
|
class MergedLoadStoreMotion {
|
|
|
|
AliasAnalysis *AA = nullptr;
|
2014-07-19 03:13:09 +08:00
|
|
|
|
2016-06-18 03:10:09 +08:00
|
|
|
// The mergeLoad/Store algorithms could have Size0 * Size1 complexity,
|
|
|
|
// where Size0 and Size1 are the #instructions on the two sides of
|
|
|
|
// the diamond. The constant chosen here is arbitrary. Compiler Time
|
|
|
|
// Control is enforced by the check Size0 * Size1 < MagicCompileTimeControl.
|
|
|
|
const int MagicCompileTimeControl = 250;
|
2016-06-17 01:40:53 +08:00
|
|
|
|
[MergedLoadStoreMotion] Sink stores to BB with more than 2 predecessors
If we have:
bb5:
br i1 %arg3, label %bb6, label %bb7
bb6:
%tmp = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp, align 4
br label %bb9
bb7:
%tmp8 = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp8, align 4
br label %bb9
bb9: ; preds = %bb4, %bb6, %bb7
...
We can't sink stores directly into bb9.
This patch creates new BB that is successor of %bb6 and %bb7
and sinks stores into that block.
SplitFooterBB is the parameter to the pass that controls
that behavior.
Change-Id: I7fdf50a772b84633e4b1b860e905bf7e3e29940f
Differential: https://reviews.llvm.org/D66234
llvm-svn: 371089
2019-09-06 01:00:32 +08:00
|
|
|
const bool SplitFooterBB;
|
2016-06-17 01:40:53 +08:00
|
|
|
public:
|
[MergedLoadStoreMotion] Sink stores to BB with more than 2 predecessors
If we have:
bb5:
br i1 %arg3, label %bb6, label %bb7
bb6:
%tmp = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp, align 4
br label %bb9
bb7:
%tmp8 = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp8, align 4
br label %bb9
bb9: ; preds = %bb4, %bb6, %bb7
...
We can't sink stores directly into bb9.
This patch creates new BB that is successor of %bb6 and %bb7
and sinks stores into that block.
SplitFooterBB is the parameter to the pass that controls
that behavior.
Change-Id: I7fdf50a772b84633e4b1b860e905bf7e3e29940f
Differential: https://reviews.llvm.org/D66234
llvm-svn: 371089
2019-09-06 01:00:32 +08:00
|
|
|
MergedLoadStoreMotion(bool SplitFooterBB) : SplitFooterBB(SplitFooterBB) {}
|
2018-02-23 18:41:57 +08:00
|
|
|
bool run(Function &F, AliasAnalysis &AA);
|
2016-06-17 01:40:53 +08:00
|
|
|
|
|
|
|
private:
|
|
|
|
BasicBlock *getDiamondTail(BasicBlock *BB);
|
|
|
|
bool isDiamondHead(BasicBlock *BB);
|
|
|
|
// Routines for sinking stores
|
|
|
|
StoreInst *canSinkFromBlock(BasicBlock *BB, StoreInst *SI);
|
|
|
|
PHINode *getPHIOperand(BasicBlock *BB, StoreInst *S0, StoreInst *S1);
|
|
|
|
bool isStoreSinkBarrierInRange(const Instruction &Start,
|
|
|
|
const Instruction &End, MemoryLocation Loc);
|
[MergedLoadStoreMotion] Sink stores to BB with more than 2 predecessors
If we have:
bb5:
br i1 %arg3, label %bb6, label %bb7
bb6:
%tmp = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp, align 4
br label %bb9
bb7:
%tmp8 = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp8, align 4
br label %bb9
bb9: ; preds = %bb4, %bb6, %bb7
...
We can't sink stores directly into bb9.
This patch creates new BB that is successor of %bb6 and %bb7
and sinks stores into that block.
SplitFooterBB is the parameter to the pass that controls
that behavior.
Change-Id: I7fdf50a772b84633e4b1b860e905bf7e3e29940f
Differential: https://reviews.llvm.org/D66234
llvm-svn: 371089
2019-09-06 01:00:32 +08:00
|
|
|
bool canSinkStoresAndGEPs(StoreInst *S0, StoreInst *S1) const;
|
|
|
|
void sinkStoresAndGEPs(BasicBlock *BB, StoreInst *SinkCand,
|
|
|
|
StoreInst *ElseInst);
|
2016-06-17 01:40:53 +08:00
|
|
|
bool mergeStores(BasicBlock *BB);
|
|
|
|
};
|
2016-07-10 19:28:51 +08:00
|
|
|
} // end anonymous namespace
|
2016-06-17 01:40:53 +08:00
|
|
|
|
|
|
|
///
|
2018-05-01 23:54:18 +08:00
|
|
|
/// Return tail block of a diamond.
|
2016-06-17 01:40:53 +08:00
|
|
|
///
|
|
|
|
BasicBlock *MergedLoadStoreMotion::getDiamondTail(BasicBlock *BB) {
|
|
|
|
assert(isDiamondHead(BB) && "Basic block is not head of a diamond");
|
|
|
|
return BB->getTerminator()->getSuccessor(0)->getSingleSuccessor();
|
|
|
|
}
|
|
|
|
|
2014-07-19 03:13:09 +08:00
|
|
|
///
|
2018-05-01 23:54:18 +08:00
|
|
|
/// True when BB is the head of a diamond (hammock)
|
2014-07-19 03:13:09 +08:00
|
|
|
///
|
2016-06-17 01:40:53 +08:00
|
|
|
bool MergedLoadStoreMotion::isDiamondHead(BasicBlock *BB) {
|
2014-07-19 03:13:09 +08:00
|
|
|
if (!BB)
|
|
|
|
return false;
|
2016-05-26 13:43:12 +08:00
|
|
|
auto *BI = dyn_cast<BranchInst>(BB->getTerminator());
|
|
|
|
if (!BI || !BI->isConditional())
|
2014-07-19 03:13:09 +08:00
|
|
|
return false;
|
|
|
|
|
|
|
|
BasicBlock *Succ0 = BI->getSuccessor(0);
|
|
|
|
BasicBlock *Succ1 = BI->getSuccessor(1);
|
|
|
|
|
2016-05-26 13:43:12 +08:00
|
|
|
if (!Succ0->getSinglePredecessor())
|
2014-07-19 03:13:09 +08:00
|
|
|
return false;
|
2016-05-26 13:43:12 +08:00
|
|
|
if (!Succ1->getSinglePredecessor())
|
2014-07-19 03:13:09 +08:00
|
|
|
return false;
|
|
|
|
|
2016-05-26 13:43:12 +08:00
|
|
|
BasicBlock *Succ0Succ = Succ0->getSingleSuccessor();
|
|
|
|
BasicBlock *Succ1Succ = Succ1->getSingleSuccessor();
|
2014-07-19 03:13:09 +08:00
|
|
|
// Ignore triangles.
|
2016-05-26 13:43:12 +08:00
|
|
|
if (!Succ0Succ || !Succ1Succ || Succ0Succ != Succ1Succ)
|
2014-07-19 03:13:09 +08:00
|
|
|
return false;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
///
|
2018-05-01 23:54:18 +08:00
|
|
|
/// True when instruction is a sink barrier for a store
|
2014-12-15 22:09:53 +08:00
|
|
|
/// located in Loc
|
|
|
|
///
|
|
|
|
/// Whenever an instruction could possibly read or modify the
|
|
|
|
/// value being stored or protect against the store from
|
|
|
|
/// happening it is considered a sink barrier.
|
|
|
|
///
|
2016-06-17 01:40:53 +08:00
|
|
|
bool MergedLoadStoreMotion::isStoreSinkBarrierInRange(const Instruction &Start,
|
|
|
|
const Instruction &End,
|
|
|
|
MemoryLocation Loc) {
|
2016-05-26 15:11:09 +08:00
|
|
|
for (const Instruction &Inst :
|
|
|
|
make_range(Start.getIterator(), End.getIterator()))
|
|
|
|
if (Inst.mayThrow())
|
|
|
|
return true;
|
2017-12-08 06:41:34 +08:00
|
|
|
return AA->canInstructionRangeModRef(Start, End, Loc, ModRefInfo::ModRef);
|
2014-07-19 03:13:09 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
///
|
2018-05-01 23:54:18 +08:00
|
|
|
/// Check if \p BB contains a store to the same address as \p SI
|
2014-07-19 03:13:09 +08:00
|
|
|
///
|
|
|
|
/// \return The store in \p when it is safe to sink. Otherwise return Null.
|
|
|
|
///
|
2016-06-17 01:40:53 +08:00
|
|
|
StoreInst *MergedLoadStoreMotion::canSinkFromBlock(BasicBlock *BB1,
|
|
|
|
StoreInst *Store0) {
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(dbgs() << "can Sink? : "; Store0->dump(); dbgs() << "\n");
|
2015-02-17 21:10:05 +08:00
|
|
|
BasicBlock *BB0 = Store0->getParent();
|
2016-06-24 12:05:21 +08:00
|
|
|
for (Instruction &Inst : reverse(*BB1)) {
|
|
|
|
auto *Store1 = dyn_cast<StoreInst>(&Inst);
|
2016-05-26 15:11:09 +08:00
|
|
|
if (!Store1)
|
|
|
|
continue;
|
2014-12-15 22:09:53 +08:00
|
|
|
|
2015-06-17 15:18:54 +08:00
|
|
|
MemoryLocation Loc0 = MemoryLocation::get(Store0);
|
|
|
|
MemoryLocation Loc1 = MemoryLocation::get(Store1);
|
2014-12-15 22:09:53 +08:00
|
|
|
if (AA->isMustAlias(Loc0, Loc1) && Store0->isSameOperationAs(Store1) &&
|
2016-06-17 01:40:53 +08:00
|
|
|
!isStoreSinkBarrierInRange(*Store1->getNextNode(), BB1->back(), Loc1) &&
|
|
|
|
!isStoreSinkBarrierInRange(*Store0->getNextNode(), BB0->back(), Loc0)) {
|
2014-12-15 22:09:53 +08:00
|
|
|
return Store1;
|
2014-07-19 03:13:09 +08:00
|
|
|
}
|
|
|
|
}
|
2014-12-15 22:09:53 +08:00
|
|
|
return nullptr;
|
2014-07-19 03:13:09 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
///
|
2018-05-01 23:54:18 +08:00
|
|
|
/// Create a PHI node in BB for the operands of S0 and S1
|
2014-07-19 03:13:09 +08:00
|
|
|
///
|
2016-06-17 01:40:53 +08:00
|
|
|
PHINode *MergedLoadStoreMotion::getPHIOperand(BasicBlock *BB, StoreInst *S0,
|
|
|
|
StoreInst *S1) {
|
2014-07-19 03:13:09 +08:00
|
|
|
// Create a phi if the values mismatch.
|
|
|
|
Value *Opd1 = S0->getValueOperand();
|
|
|
|
Value *Opd2 = S1->getValueOperand();
|
2016-05-26 13:43:12 +08:00
|
|
|
if (Opd1 == Opd2)
|
|
|
|
return nullptr;
|
|
|
|
|
|
|
|
auto *NewPN = PHINode::Create(Opd1->getType(), 2, Opd2->getName() + ".sink",
|
|
|
|
&BB->front());
|
2018-11-03 02:25:41 +08:00
|
|
|
NewPN->applyMergedLocation(S0->getDebugLoc(), S1->getDebugLoc());
|
2016-05-26 13:43:12 +08:00
|
|
|
NewPN->addIncoming(Opd1, S0->getParent());
|
|
|
|
NewPN->addIncoming(Opd2, S1->getParent());
|
2014-07-19 03:13:09 +08:00
|
|
|
return NewPN;
|
|
|
|
}
|
|
|
|
|
[MergedLoadStoreMotion] Sink stores to BB with more than 2 predecessors
If we have:
bb5:
br i1 %arg3, label %bb6, label %bb7
bb6:
%tmp = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp, align 4
br label %bb9
bb7:
%tmp8 = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp8, align 4
br label %bb9
bb9: ; preds = %bb4, %bb6, %bb7
...
We can't sink stores directly into bb9.
This patch creates new BB that is successor of %bb6 and %bb7
and sinks stores into that block.
SplitFooterBB is the parameter to the pass that controls
that behavior.
Change-Id: I7fdf50a772b84633e4b1b860e905bf7e3e29940f
Differential: https://reviews.llvm.org/D66234
llvm-svn: 371089
2019-09-06 01:00:32 +08:00
|
|
|
///
|
|
|
|
/// Check if 2 stores can be sunk together with corresponding GEPs
|
|
|
|
///
|
|
|
|
bool MergedLoadStoreMotion::canSinkStoresAndGEPs(StoreInst *S0,
|
|
|
|
StoreInst *S1) const {
|
|
|
|
auto *A0 = dyn_cast<Instruction>(S0->getPointerOperand());
|
|
|
|
auto *A1 = dyn_cast<Instruction>(S1->getPointerOperand());
|
|
|
|
return A0 && A1 && A0->isIdenticalTo(A1) && A0->hasOneUse() &&
|
|
|
|
(A0->getParent() == S0->getParent()) && A1->hasOneUse() &&
|
|
|
|
(A1->getParent() == S1->getParent()) && isa<GetElementPtrInst>(A0);
|
|
|
|
}
|
|
|
|
|
2014-07-19 03:13:09 +08:00
|
|
|
///
|
2018-05-01 23:54:18 +08:00
|
|
|
/// Merge two stores to same address and sink into \p BB
|
2014-07-19 03:13:09 +08:00
|
|
|
///
|
|
|
|
/// Also sinks GEP instruction computing the store address
|
|
|
|
///
|
[MergedLoadStoreMotion] Sink stores to BB with more than 2 predecessors
If we have:
bb5:
br i1 %arg3, label %bb6, label %bb7
bb6:
%tmp = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp, align 4
br label %bb9
bb7:
%tmp8 = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp8, align 4
br label %bb9
bb9: ; preds = %bb4, %bb6, %bb7
...
We can't sink stores directly into bb9.
This patch creates new BB that is successor of %bb6 and %bb7
and sinks stores into that block.
SplitFooterBB is the parameter to the pass that controls
that behavior.
Change-Id: I7fdf50a772b84633e4b1b860e905bf7e3e29940f
Differential: https://reviews.llvm.org/D66234
llvm-svn: 371089
2019-09-06 01:00:32 +08:00
|
|
|
void MergedLoadStoreMotion::sinkStoresAndGEPs(BasicBlock *BB, StoreInst *S0,
|
|
|
|
StoreInst *S1) {
|
2014-07-19 03:13:09 +08:00
|
|
|
// Only one definition?
|
2016-05-26 13:43:12 +08:00
|
|
|
auto *A0 = dyn_cast<Instruction>(S0->getPointerOperand());
|
|
|
|
auto *A1 = dyn_cast<Instruction>(S1->getPointerOperand());
|
[MergedLoadStoreMotion] Sink stores to BB with more than 2 predecessors
If we have:
bb5:
br i1 %arg3, label %bb6, label %bb7
bb6:
%tmp = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp, align 4
br label %bb9
bb7:
%tmp8 = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp8, align 4
br label %bb9
bb9: ; preds = %bb4, %bb6, %bb7
...
We can't sink stores directly into bb9.
This patch creates new BB that is successor of %bb6 and %bb7
and sinks stores into that block.
SplitFooterBB is the parameter to the pass that controls
that behavior.
Change-Id: I7fdf50a772b84633e4b1b860e905bf7e3e29940f
Differential: https://reviews.llvm.org/D66234
llvm-svn: 371089
2019-09-06 01:00:32 +08:00
|
|
|
LLVM_DEBUG(dbgs() << "Sink Instruction into BB \n"; BB->dump();
|
|
|
|
dbgs() << "Instruction Left\n"; S0->dump(); dbgs() << "\n";
|
|
|
|
dbgs() << "Instruction Right\n"; S1->dump(); dbgs() << "\n");
|
|
|
|
// Hoist the instruction.
|
|
|
|
BasicBlock::iterator InsertPt = BB->getFirstInsertionPt();
|
|
|
|
// Intersect optional metadata.
|
|
|
|
S0->andIRFlags(S1);
|
|
|
|
S0->dropUnknownNonDebugMetadata();
|
|
|
|
|
|
|
|
// Create the new store to be inserted at the join point.
|
|
|
|
StoreInst *SNew = cast<StoreInst>(S0->clone());
|
|
|
|
Instruction *ANew = A0->clone();
|
|
|
|
SNew->insertBefore(&*InsertPt);
|
|
|
|
ANew->insertBefore(SNew);
|
|
|
|
|
|
|
|
assert(S0->getParent() == A0->getParent());
|
|
|
|
assert(S1->getParent() == A1->getParent());
|
|
|
|
|
|
|
|
// New PHI operand? Use it.
|
|
|
|
if (PHINode *NewPN = getPHIOperand(BB, S0, S1))
|
|
|
|
SNew->setOperand(0, NewPN);
|
|
|
|
S0->eraseFromParent();
|
|
|
|
S1->eraseFromParent();
|
|
|
|
A0->replaceAllUsesWith(ANew);
|
|
|
|
A0->eraseFromParent();
|
|
|
|
A1->replaceAllUsesWith(ANew);
|
|
|
|
A1->eraseFromParent();
|
2014-07-19 03:13:09 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
///
|
2018-05-01 23:54:18 +08:00
|
|
|
/// True when two stores are equivalent and can sink into the footer
|
2014-07-19 03:13:09 +08:00
|
|
|
///
|
[MergedLoadStoreMotion] Sink stores to BB with more than 2 predecessors
If we have:
bb5:
br i1 %arg3, label %bb6, label %bb7
bb6:
%tmp = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp, align 4
br label %bb9
bb7:
%tmp8 = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp8, align 4
br label %bb9
bb9: ; preds = %bb4, %bb6, %bb7
...
We can't sink stores directly into bb9.
This patch creates new BB that is successor of %bb6 and %bb7
and sinks stores into that block.
SplitFooterBB is the parameter to the pass that controls
that behavior.
Change-Id: I7fdf50a772b84633e4b1b860e905bf7e3e29940f
Differential: https://reviews.llvm.org/D66234
llvm-svn: 371089
2019-09-06 01:00:32 +08:00
|
|
|
/// Starting from a diamond head block, iterate over the instructions in one
|
|
|
|
/// successor block and try to match a store in the second successor.
|
2014-07-19 03:13:09 +08:00
|
|
|
///
|
[MergedLoadStoreMotion] Sink stores to BB with more than 2 predecessors
If we have:
bb5:
br i1 %arg3, label %bb6, label %bb7
bb6:
%tmp = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp, align 4
br label %bb9
bb7:
%tmp8 = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp8, align 4
br label %bb9
bb9: ; preds = %bb4, %bb6, %bb7
...
We can't sink stores directly into bb9.
This patch creates new BB that is successor of %bb6 and %bb7
and sinks stores into that block.
SplitFooterBB is the parameter to the pass that controls
that behavior.
Change-Id: I7fdf50a772b84633e4b1b860e905bf7e3e29940f
Differential: https://reviews.llvm.org/D66234
llvm-svn: 371089
2019-09-06 01:00:32 +08:00
|
|
|
bool MergedLoadStoreMotion::mergeStores(BasicBlock *HeadBB) {
|
2014-07-19 03:13:09 +08:00
|
|
|
|
|
|
|
bool MergedStores = false;
|
[MergedLoadStoreMotion] Sink stores to BB with more than 2 predecessors
If we have:
bb5:
br i1 %arg3, label %bb6, label %bb7
bb6:
%tmp = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp, align 4
br label %bb9
bb7:
%tmp8 = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp8, align 4
br label %bb9
bb9: ; preds = %bb4, %bb6, %bb7
...
We can't sink stores directly into bb9.
This patch creates new BB that is successor of %bb6 and %bb7
and sinks stores into that block.
SplitFooterBB is the parameter to the pass that controls
that behavior.
Change-Id: I7fdf50a772b84633e4b1b860e905bf7e3e29940f
Differential: https://reviews.llvm.org/D66234
llvm-svn: 371089
2019-09-06 01:00:32 +08:00
|
|
|
BasicBlock *TailBB = getDiamondTail(HeadBB);
|
|
|
|
BasicBlock *SinkBB = TailBB;
|
|
|
|
assert(SinkBB && "Footer of a diamond cannot be empty");
|
|
|
|
|
|
|
|
succ_iterator SI = succ_begin(HeadBB);
|
|
|
|
assert(SI != succ_end(HeadBB) && "Diamond head cannot have zero successors");
|
|
|
|
BasicBlock *Pred0 = *SI;
|
|
|
|
++SI;
|
|
|
|
assert(SI != succ_end(HeadBB) && "Diamond head cannot have single successor");
|
|
|
|
BasicBlock *Pred1 = *SI;
|
2014-07-19 03:13:09 +08:00
|
|
|
// tail block of a diamond/hammock?
|
|
|
|
if (Pred0 == Pred1)
|
|
|
|
return false; // No.
|
[MergedLoadStoreMotion] Sink stores to BB with more than 2 predecessors
If we have:
bb5:
br i1 %arg3, label %bb6, label %bb7
bb6:
%tmp = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp, align 4
br label %bb9
bb7:
%tmp8 = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp8, align 4
br label %bb9
bb9: ; preds = %bb4, %bb6, %bb7
...
We can't sink stores directly into bb9.
This patch creates new BB that is successor of %bb6 and %bb7
and sinks stores into that block.
SplitFooterBB is the parameter to the pass that controls
that behavior.
Change-Id: I7fdf50a772b84633e4b1b860e905bf7e3e29940f
Differential: https://reviews.llvm.org/D66234
llvm-svn: 371089
2019-09-06 01:00:32 +08:00
|
|
|
// bail out early if we can not merge into the footer BB
|
|
|
|
if (!SplitFooterBB && TailBB->hasNPredecessorsOrMore(3))
|
|
|
|
return false;
|
|
|
|
// #Instructions in Pred1 for Compile Time Control
|
2018-05-17 07:20:42 +08:00
|
|
|
auto InstsNoDbg = Pred1->instructionsWithoutDebug();
|
|
|
|
int Size1 = std::distance(InstsNoDbg.begin(), InstsNoDbg.end());
|
2014-07-19 03:13:09 +08:00
|
|
|
int NStores = 0;
|
|
|
|
|
|
|
|
for (BasicBlock::reverse_iterator RBI = Pred0->rbegin(), RBE = Pred0->rend();
|
|
|
|
RBI != RBE;) {
|
|
|
|
|
|
|
|
Instruction *I = &*RBI;
|
|
|
|
++RBI;
|
2014-12-15 22:09:53 +08:00
|
|
|
|
2016-05-26 13:43:12 +08:00
|
|
|
// Don't sink non-simple (atomic, volatile) stores.
|
|
|
|
auto *S0 = dyn_cast<StoreInst>(I);
|
|
|
|
if (!S0 || !S0->isSimple())
|
2014-07-19 03:13:09 +08:00
|
|
|
continue;
|
|
|
|
|
|
|
|
++NStores;
|
|
|
|
if (NStores * Size1 >= MagicCompileTimeControl)
|
|
|
|
break;
|
2016-06-17 01:40:53 +08:00
|
|
|
if (StoreInst *S1 = canSinkFromBlock(Pred1, S0)) {
|
[MergedLoadStoreMotion] Sink stores to BB with more than 2 predecessors
If we have:
bb5:
br i1 %arg3, label %bb6, label %bb7
bb6:
%tmp = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp, align 4
br label %bb9
bb7:
%tmp8 = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp8, align 4
br label %bb9
bb9: ; preds = %bb4, %bb6, %bb7
...
We can't sink stores directly into bb9.
This patch creates new BB that is successor of %bb6 and %bb7
and sinks stores into that block.
SplitFooterBB is the parameter to the pass that controls
that behavior.
Change-Id: I7fdf50a772b84633e4b1b860e905bf7e3e29940f
Differential: https://reviews.llvm.org/D66234
llvm-svn: 371089
2019-09-06 01:00:32 +08:00
|
|
|
if (!canSinkStoresAndGEPs(S0, S1))
|
|
|
|
// Don't attempt to sink below stores that had to stick around
|
|
|
|
// But after removal of a store and some of its feeding
|
|
|
|
// instruction search again from the beginning since the iterator
|
|
|
|
// is likely stale at this point.
|
2014-07-19 03:13:09 +08:00
|
|
|
break;
|
[MergedLoadStoreMotion] Sink stores to BB with more than 2 predecessors
If we have:
bb5:
br i1 %arg3, label %bb6, label %bb7
bb6:
%tmp = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp, align 4
br label %bb9
bb7:
%tmp8 = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp8, align 4
br label %bb9
bb9: ; preds = %bb4, %bb6, %bb7
...
We can't sink stores directly into bb9.
This patch creates new BB that is successor of %bb6 and %bb7
and sinks stores into that block.
SplitFooterBB is the parameter to the pass that controls
that behavior.
Change-Id: I7fdf50a772b84633e4b1b860e905bf7e3e29940f
Differential: https://reviews.llvm.org/D66234
llvm-svn: 371089
2019-09-06 01:00:32 +08:00
|
|
|
|
|
|
|
if (SinkBB == TailBB && TailBB->hasNPredecessorsOrMore(3)) {
|
|
|
|
// We have more than 2 predecessors. Insert a new block
|
|
|
|
// postdominating 2 predecessors we're going to sink from.
|
|
|
|
SinkBB = SplitBlockPredecessors(TailBB, {Pred0, Pred1}, ".sink.split");
|
|
|
|
if (!SinkBB)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
MergedStores = true;
|
|
|
|
sinkStoresAndGEPs(SinkBB, S0, S1);
|
2016-05-26 13:43:12 +08:00
|
|
|
RBI = Pred0->rbegin();
|
|
|
|
RBE = Pred0->rend();
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(dbgs() << "Search again\n"; Instruction *I = &*RBI; I->dump());
|
2014-07-19 03:13:09 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
return MergedStores;
|
|
|
|
}
|
2015-10-07 07:24:35 +08:00
|
|
|
|
2018-02-23 18:41:57 +08:00
|
|
|
bool MergedLoadStoreMotion::run(Function &F, AliasAnalysis &AA) {
|
2016-06-18 03:10:09 +08:00
|
|
|
this->AA = &AA;
|
2016-06-17 01:40:53 +08:00
|
|
|
|
2014-07-19 03:13:09 +08:00
|
|
|
bool Changed = false;
|
2018-05-14 20:53:11 +08:00
|
|
|
LLVM_DEBUG(dbgs() << "Instruction Merger\n");
|
2014-07-19 03:13:09 +08:00
|
|
|
|
|
|
|
// Merge unconditional branches, allowing PRE to catch more
|
|
|
|
// optimization opportunities.
|
[MergedLoadStoreMotion] Sink stores to BB with more than 2 predecessors
If we have:
bb5:
br i1 %arg3, label %bb6, label %bb7
bb6:
%tmp = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp, align 4
br label %bb9
bb7:
%tmp8 = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp8, align 4
br label %bb9
bb9: ; preds = %bb4, %bb6, %bb7
...
We can't sink stores directly into bb9.
This patch creates new BB that is successor of %bb6 and %bb7
and sinks stores into that block.
SplitFooterBB is the parameter to the pass that controls
that behavior.
Change-Id: I7fdf50a772b84633e4b1b860e905bf7e3e29940f
Differential: https://reviews.llvm.org/D66234
llvm-svn: 371089
2019-09-06 01:00:32 +08:00
|
|
|
// This loop doesn't care about newly inserted/split blocks
|
|
|
|
// since they never will be diamond heads.
|
2020-02-02 15:57:22 +08:00
|
|
|
for (BasicBlock &BB : make_early_inc_range(F))
|
2014-07-19 03:13:09 +08:00
|
|
|
// Hoist equivalent loads and sink stores
|
|
|
|
// outside diamonds when possible
|
2020-02-02 15:57:22 +08:00
|
|
|
if (isDiamondHead(&BB))
|
|
|
|
Changed |= mergeStores(&BB);
|
2014-07-19 03:13:09 +08:00
|
|
|
return Changed;
|
|
|
|
}
|
2016-06-18 03:10:09 +08:00
|
|
|
|
|
|
|
namespace {
|
|
|
|
class MergedLoadStoreMotionLegacyPass : public FunctionPass {
|
[MergedLoadStoreMotion] Sink stores to BB with more than 2 predecessors
If we have:
bb5:
br i1 %arg3, label %bb6, label %bb7
bb6:
%tmp = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp, align 4
br label %bb9
bb7:
%tmp8 = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp8, align 4
br label %bb9
bb9: ; preds = %bb4, %bb6, %bb7
...
We can't sink stores directly into bb9.
This patch creates new BB that is successor of %bb6 and %bb7
and sinks stores into that block.
SplitFooterBB is the parameter to the pass that controls
that behavior.
Change-Id: I7fdf50a772b84633e4b1b860e905bf7e3e29940f
Differential: https://reviews.llvm.org/D66234
llvm-svn: 371089
2019-09-06 01:00:32 +08:00
|
|
|
const bool SplitFooterBB;
|
2016-06-18 03:10:09 +08:00
|
|
|
public:
|
|
|
|
static char ID; // Pass identification, replacement for typeid
|
[MergedLoadStoreMotion] Sink stores to BB with more than 2 predecessors
If we have:
bb5:
br i1 %arg3, label %bb6, label %bb7
bb6:
%tmp = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp, align 4
br label %bb9
bb7:
%tmp8 = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp8, align 4
br label %bb9
bb9: ; preds = %bb4, %bb6, %bb7
...
We can't sink stores directly into bb9.
This patch creates new BB that is successor of %bb6 and %bb7
and sinks stores into that block.
SplitFooterBB is the parameter to the pass that controls
that behavior.
Change-Id: I7fdf50a772b84633e4b1b860e905bf7e3e29940f
Differential: https://reviews.llvm.org/D66234
llvm-svn: 371089
2019-09-06 01:00:32 +08:00
|
|
|
MergedLoadStoreMotionLegacyPass(bool SplitFooterBB = false)
|
|
|
|
: FunctionPass(ID), SplitFooterBB(SplitFooterBB) {
|
2016-06-18 03:10:09 +08:00
|
|
|
initializeMergedLoadStoreMotionLegacyPassPass(
|
|
|
|
*PassRegistry::getPassRegistry());
|
|
|
|
}
|
|
|
|
|
|
|
|
///
|
2018-05-01 23:54:18 +08:00
|
|
|
/// Run the transformation for each function
|
2016-06-18 03:10:09 +08:00
|
|
|
///
|
|
|
|
bool runOnFunction(Function &F) override {
|
|
|
|
if (skipFunction(F))
|
|
|
|
return false;
|
[MergedLoadStoreMotion] Sink stores to BB with more than 2 predecessors
If we have:
bb5:
br i1 %arg3, label %bb6, label %bb7
bb6:
%tmp = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp, align 4
br label %bb9
bb7:
%tmp8 = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp8, align 4
br label %bb9
bb9: ; preds = %bb4, %bb6, %bb7
...
We can't sink stores directly into bb9.
This patch creates new BB that is successor of %bb6 and %bb7
and sinks stores into that block.
SplitFooterBB is the parameter to the pass that controls
that behavior.
Change-Id: I7fdf50a772b84633e4b1b860e905bf7e3e29940f
Differential: https://reviews.llvm.org/D66234
llvm-svn: 371089
2019-09-06 01:00:32 +08:00
|
|
|
MergedLoadStoreMotion Impl(SplitFooterBB);
|
2018-02-23 18:41:57 +08:00
|
|
|
return Impl.run(F, getAnalysis<AAResultsWrapperPass>().getAAResults());
|
2016-06-18 03:10:09 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
void getAnalysisUsage(AnalysisUsage &AU) const override {
|
[MergedLoadStoreMotion] Sink stores to BB with more than 2 predecessors
If we have:
bb5:
br i1 %arg3, label %bb6, label %bb7
bb6:
%tmp = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp, align 4
br label %bb9
bb7:
%tmp8 = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp8, align 4
br label %bb9
bb9: ; preds = %bb4, %bb6, %bb7
...
We can't sink stores directly into bb9.
This patch creates new BB that is successor of %bb6 and %bb7
and sinks stores into that block.
SplitFooterBB is the parameter to the pass that controls
that behavior.
Change-Id: I7fdf50a772b84633e4b1b860e905bf7e3e29940f
Differential: https://reviews.llvm.org/D66234
llvm-svn: 371089
2019-09-06 01:00:32 +08:00
|
|
|
if (!SplitFooterBB)
|
|
|
|
AU.setPreservesCFG();
|
2016-06-18 03:10:09 +08:00
|
|
|
AU.addRequired<AAResultsWrapperPass>();
|
|
|
|
AU.addPreserved<GlobalsAAWrapperPass>();
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
char MergedLoadStoreMotionLegacyPass::ID = 0;
|
|
|
|
} // anonymous namespace
|
|
|
|
|
|
|
|
///
|
2018-05-01 23:54:18 +08:00
|
|
|
/// createMergedLoadStoreMotionPass - The public interface to this file.
|
2016-06-18 03:10:09 +08:00
|
|
|
///
|
[MergedLoadStoreMotion] Sink stores to BB with more than 2 predecessors
If we have:
bb5:
br i1 %arg3, label %bb6, label %bb7
bb6:
%tmp = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp, align 4
br label %bb9
bb7:
%tmp8 = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp8, align 4
br label %bb9
bb9: ; preds = %bb4, %bb6, %bb7
...
We can't sink stores directly into bb9.
This patch creates new BB that is successor of %bb6 and %bb7
and sinks stores into that block.
SplitFooterBB is the parameter to the pass that controls
that behavior.
Change-Id: I7fdf50a772b84633e4b1b860e905bf7e3e29940f
Differential: https://reviews.llvm.org/D66234
llvm-svn: 371089
2019-09-06 01:00:32 +08:00
|
|
|
FunctionPass *llvm::createMergedLoadStoreMotionPass(bool SplitFooterBB) {
|
|
|
|
return new MergedLoadStoreMotionLegacyPass(SplitFooterBB);
|
2016-06-18 03:10:09 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
INITIALIZE_PASS_BEGIN(MergedLoadStoreMotionLegacyPass, "mldst-motion",
|
|
|
|
"MergedLoadStoreMotion", false, false)
|
|
|
|
INITIALIZE_PASS_DEPENDENCY(AAResultsWrapperPass)
|
|
|
|
INITIALIZE_PASS_END(MergedLoadStoreMotionLegacyPass, "mldst-motion",
|
|
|
|
"MergedLoadStoreMotion", false, false)
|
|
|
|
|
|
|
|
PreservedAnalyses
|
2016-08-09 08:28:15 +08:00
|
|
|
MergedLoadStoreMotionPass::run(Function &F, FunctionAnalysisManager &AM) {
|
[MergedLoadStoreMotion] Sink stores to BB with more than 2 predecessors
If we have:
bb5:
br i1 %arg3, label %bb6, label %bb7
bb6:
%tmp = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp, align 4
br label %bb9
bb7:
%tmp8 = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp8, align 4
br label %bb9
bb9: ; preds = %bb4, %bb6, %bb7
...
We can't sink stores directly into bb9.
This patch creates new BB that is successor of %bb6 and %bb7
and sinks stores into that block.
SplitFooterBB is the parameter to the pass that controls
that behavior.
Change-Id: I7fdf50a772b84633e4b1b860e905bf7e3e29940f
Differential: https://reviews.llvm.org/D66234
llvm-svn: 371089
2019-09-06 01:00:32 +08:00
|
|
|
MergedLoadStoreMotion Impl(Options.SplitFooterBB);
|
2016-06-18 03:10:09 +08:00
|
|
|
auto &AA = AM.getResult<AAManager>(F);
|
2018-02-23 18:41:57 +08:00
|
|
|
if (!Impl.run(F, AA))
|
2016-06-18 03:10:09 +08:00
|
|
|
return PreservedAnalyses::all();
|
|
|
|
|
|
|
|
PreservedAnalyses PA;
|
[MergedLoadStoreMotion] Sink stores to BB with more than 2 predecessors
If we have:
bb5:
br i1 %arg3, label %bb6, label %bb7
bb6:
%tmp = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp, align 4
br label %bb9
bb7:
%tmp8 = getelementptr inbounds i32, i32* %arg1, i64 2
store i32 3, i32* %tmp8, align 4
br label %bb9
bb9: ; preds = %bb4, %bb6, %bb7
...
We can't sink stores directly into bb9.
This patch creates new BB that is successor of %bb6 and %bb7
and sinks stores into that block.
SplitFooterBB is the parameter to the pass that controls
that behavior.
Change-Id: I7fdf50a772b84633e4b1b860e905bf7e3e29940f
Differential: https://reviews.llvm.org/D66234
llvm-svn: 371089
2019-09-06 01:00:32 +08:00
|
|
|
if (!Options.SplitFooterBB)
|
|
|
|
PA.preserveSet<CFGAnalyses>();
|
2016-06-18 03:10:09 +08:00
|
|
|
PA.preserve<GlobalsAA>();
|
|
|
|
return PA;
|
|
|
|
}
|