2003-09-30 18:37:50 +00:00
|
|
|
//===-- Scalar.h - Scalar Transformations -----------------------*- C++ -*-===//
|
2005-04-21 20:59:05 +00:00
|
|
|
//
|
2003-10-20 20:19:47 +00:00
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
2007-12-29 19:59:42 +00:00
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
2005-04-21 20:59:05 +00:00
|
|
|
//
|
2003-10-20 20:19:47 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
2002-05-07 19:37:18 +00:00
|
|
|
//
|
|
|
|
// This header file defines prototypes for accessor functions that expose passes
|
|
|
|
// in the Scalar transformations library.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#ifndef LLVM_TRANSFORMS_SCALAR_H
|
|
|
|
#define LLVM_TRANSFORMS_SCALAR_H
|
|
|
|
|
SampleProfileLoader pass. Initial setup.
This adds a new scalar pass that reads a file with samples generated
by 'perf' during runtime. The samples read from the profile are
incorporated and emmited as IR metadata reflecting that profile.
The profile file is assumed to have been generated by an external
profile source. The profile information is converted into IR metadata,
which is later used by the analysis routines to estimate block
frequencies, edge weights and other related data.
External profile information files have no fixed format, each profiler
is free to define its own. This includes both the on-disk representation
of the profile and the kind of profile information stored in the file.
A common kind of profile is based on sampling (e.g., perf), which
essentially counts how many times each line of the program has been
executed during the run.
The SampleProfileLoader pass is organized as a scalar transformation.
On startup, it reads the file given in -sample-profile-file to
determine what kind of profile it contains. This file is assumed to
contain profile information for the whole application. The profile
data in the file is read and incorporated into the internal state of
the corresponding profiler.
To facilitate testing, I've organized the profilers to support two file
formats: text and native. The native format is whatever on-disk
representation the profiler wants to support, I think this will mostly
be bitcode files, but it could be anything the profiler wants to
support. To do this, every profiler must implement the
SampleProfile::loadNative() function.
The text format is mostly meant for debugging. Records are separated by
newlines, but each profiler is free to interpret records as it sees fit.
Profilers must implement the SampleProfile::loadText() function.
Finally, the pass will call SampleProfile::emitAnnotations() for each
function in the current translation unit. This function needs to
translate the loaded profile into IR metadata, which the analyzer will
later be able to use.
This patch implements the first steps towards the above design. I've
implemented a sample-based flat profiler. The format of the profile is
fairly simplistic. Each sampled function contains a list of relative
line locations (from the start of the function) together with a count
representing how many samples were collected at that line during
execution. I generate this profile using perf and a separate converter
tool.
Currently, I have only implemented a text format for these profiles. I
am interested in initial feedback to the whole approach before I send
the other parts of the implementation for review.
This patch implements:
- The SampleProfileLoader pass.
- The base ExternalProfile class with the core interface.
- A SampleProfile sub-class using the above interface. The profiler
generates branch weight metadata on every branch instructions that
matches the profiles.
- A text loader class to assist the implementation of
SampleProfile::loadText().
- Basic unit tests for the pass.
Additionally, the patch uses profile information to compute branch
weights based on instruction samples.
This patch converts instruction samples into branch weights. It
does a fairly simplistic conversion:
Given a multi-way branch instruction, it calculates the weight of
each branch based on the maximum sample count gathered from each
target basic block.
Note that this assignment of branch weights is somewhat lossy and can be
misleading. If a basic block has more than one incoming branch, all the
incoming branches will get the same weight. In reality, it may be that
only one of them is the most heavily taken branch.
I will adjust this assignment in subsequent patches.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194566 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-13 12:22:21 +00:00
|
|
|
#include "llvm/ADT/StringRef.h"
|
|
|
|
|
2003-11-11 22:41:34 +00:00
|
|
|
namespace llvm {
|
|
|
|
|
2003-08-13 18:18:15 +00:00
|
|
|
class FunctionPass;
|
2007-01-25 23:23:25 +00:00
|
|
|
class Pass;
|
2002-09-16 16:07:19 +00:00
|
|
|
class GetElementPtrInst;
|
2002-09-24 15:42:27 +00:00
|
|
|
class PassInfo;
|
2002-10-08 21:06:27 +00:00
|
|
|
class TerminatorInst;
|
2006-03-13 23:14:23 +00:00
|
|
|
class TargetLowering;
|
2013-06-19 21:07:11 +00:00
|
|
|
class TargetMachine;
|
2002-05-07 19:37:18 +00:00
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
2006-10-13 20:53:50 +00:00
|
|
|
// ConstantPropagation - A worklist driven constant propagation pass
|
2002-05-07 19:37:18 +00:00
|
|
|
//
|
2004-09-20 04:41:39 +00:00
|
|
|
FunctionPass *createConstantPropagationPass();
|
2002-05-07 19:37:18 +00:00
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
2006-10-13 20:53:50 +00:00
|
|
|
// SCCP - Sparse conditional constant propagation.
|
2002-05-07 19:37:18 +00:00
|
|
|
//
|
2004-09-20 04:41:39 +00:00
|
|
|
FunctionPass *createSCCPPass();
|
2002-05-07 19:37:18 +00:00
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// DeadInstElimination - This pass quickly removes trivially dead instructions
|
|
|
|
// without modifying the CFG of the function. It is a BasicBlockPass, so it
|
|
|
|
// runs efficiently when queued next to other BasicBlockPass's.
|
|
|
|
//
|
2007-01-25 23:23:25 +00:00
|
|
|
Pass *createDeadInstEliminationPass();
|
2002-05-07 19:37:18 +00:00
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// DeadCodeElimination - This pass is more powerful than DeadInstElimination,
|
|
|
|
// because it is worklist driven that can potentially revisit instructions when
|
|
|
|
// their other instructions become dead, to eliminate chains of dead
|
|
|
|
// computations.
|
|
|
|
//
|
2004-07-27 17:43:21 +00:00
|
|
|
FunctionPass *createDeadCodeEliminationPass();
|
2002-05-07 19:37:18 +00:00
|
|
|
|
2004-07-22 08:07:30 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// DeadStoreElimination - This pass deletes stores that are post-dominated by
|
|
|
|
// must-aliased stores and are not loaded used between the stores.
|
|
|
|
//
|
2004-09-20 04:41:39 +00:00
|
|
|
FunctionPass *createDeadStoreEliminationPass();
|
2002-05-07 19:37:18 +00:00
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
2002-05-07 22:12:52 +00:00
|
|
|
// AggressiveDCE - This pass uses the SSA based Aggressive DCE algorithm. This
|
2002-05-07 19:37:18 +00:00
|
|
|
// algorithm assumes instructions are dead until proven otherwise, which makes
|
|
|
|
// it more successful are removing non-obviously dead instructions.
|
|
|
|
//
|
2004-09-20 04:41:39 +00:00
|
|
|
FunctionPass *createAggressiveDCEPass();
|
2002-05-07 19:37:18 +00:00
|
|
|
|
Introduce a new SROA implementation.
This is essentially a ground up re-think of the SROA pass in LLVM. It
was initially inspired by a few problems with the existing pass:
- It is subject to the bane of my existence in optimizations: arbitrary
thresholds.
- It is overly conservative about which constructs can be split and
promoted.
- The vector value replacement aspect is separated from the splitting
logic, missing many opportunities where splitting and vector value
formation can work together.
- The splitting is entirely based around the underlying type of the
alloca, despite this type often having little to do with the reality
of how that memory is used. This is especially prevelant with unions
and base classes where we tail-pack derived members.
- When splitting fails (often due to the thresholds), the vector value
replacement (again because it is separate) can kick in for
preposterous cases where we simply should have split the value. This
results in forming i1024 and i2048 integer "bit vectors" that
tremendously slow down subsequnet IR optimizations (due to large
APInts) and impede the backend's lowering.
The new design takes an approach that fundamentally is not susceptible
to many of these problems. It is the result of a discusison between
myself and Duncan Sands over IRC about how to premptively avoid these
types of problems and how to do SROA in a more principled way. Since
then, it has evolved and grown, but this remains an important aspect: it
fixes real world problems with the SROA process today.
First, the transform of SROA actually has little to do with replacement.
It has more to do with splitting. The goal is to take an aggregate
alloca and form a composition of scalar allocas which can replace it and
will be most suitable to the eventual replacement by scalar SSA values.
The actual replacement is performed by mem2reg (and in the future
SSAUpdater).
The splitting is divided into four phases. The first phase is an
analysis of the uses of the alloca. This phase recursively walks uses,
building up a dense datastructure representing the ranges of the
alloca's memory actually used and checking for uses which inhibit any
aspects of the transform such as the escape of a pointer.
Once we have a mapping of the ranges of the alloca used by individual
operations, we compute a partitioning of the used ranges. Some uses are
inherently splittable (such as memcpy and memset), while scalar uses are
not splittable. The goal is to build a partitioning that has the minimum
number of splits while placing each unsplittable use in its own
partition. Overlapping unsplittable uses belong to the same partition.
This is the target split of the aggregate alloca, and it maximizes the
number of scalar accesses which become accesses to their own alloca and
candidates for promotion.
Third, we re-walk the uses of the alloca and assign each specific memory
access to all the partitions touched so that we have dense use-lists for
each partition.
Finally, we build a new, smaller alloca for each partition and rewrite
each use of that partition to use the new alloca. During this phase the
pass will also work very hard to transform uses of an alloca into a form
suitable for promotion, including forming vector operations, speculating
loads throguh PHI nodes and selects, etc.
After splitting is complete, each newly refined alloca that is
a candidate for promotion to a scalar SSA value is run through mem2reg.
There are lots of reasonably detailed comments in the source code about
the design and algorithms, and I'm going to be trying to improve them in
subsequent commits to ensure this is well documented, as the new pass is
in many ways more complex than the old one.
Some of this is still a WIP, but the current state is reasonbly stable.
It has passed bootstrap, the nightly test suite, and Duncan has run it
successfully through the ACATS and DragonEgg test suites. That said, it
remains behind a default-off flag until the last few pieces are in
place, and full testing can be done.
Specific areas I'm looking at next:
- Improved comments and some code cleanup from reviews.
- SSAUpdater and enabling this pass inside the CGSCC pass manager.
- Some datastructure tuning and compile-time measurements.
- More aggressive FCA splitting and vector formation.
Many thanks to Duncan Sands for the thorough final review, as well as
Benjamin Kramer for lots of review during the process of writing this
pass, and Daniel Berlin for reviewing the data structures and algorithms
and general theory of the pass. Also, several other people on IRC, over
lunch tables, etc for lots of feedback and advice.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163883 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-14 09:22:59 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// SROA - Replace aggregates or pieces of aggregates with scalar SSA values.
|
|
|
|
//
|
2012-09-15 11:43:14 +00:00
|
|
|
FunctionPass *createSROAPass(bool RequiresDomTree = true);
|
Introduce a new SROA implementation.
This is essentially a ground up re-think of the SROA pass in LLVM. It
was initially inspired by a few problems with the existing pass:
- It is subject to the bane of my existence in optimizations: arbitrary
thresholds.
- It is overly conservative about which constructs can be split and
promoted.
- The vector value replacement aspect is separated from the splitting
logic, missing many opportunities where splitting and vector value
formation can work together.
- The splitting is entirely based around the underlying type of the
alloca, despite this type often having little to do with the reality
of how that memory is used. This is especially prevelant with unions
and base classes where we tail-pack derived members.
- When splitting fails (often due to the thresholds), the vector value
replacement (again because it is separate) can kick in for
preposterous cases where we simply should have split the value. This
results in forming i1024 and i2048 integer "bit vectors" that
tremendously slow down subsequnet IR optimizations (due to large
APInts) and impede the backend's lowering.
The new design takes an approach that fundamentally is not susceptible
to many of these problems. It is the result of a discusison between
myself and Duncan Sands over IRC about how to premptively avoid these
types of problems and how to do SROA in a more principled way. Since
then, it has evolved and grown, but this remains an important aspect: it
fixes real world problems with the SROA process today.
First, the transform of SROA actually has little to do with replacement.
It has more to do with splitting. The goal is to take an aggregate
alloca and form a composition of scalar allocas which can replace it and
will be most suitable to the eventual replacement by scalar SSA values.
The actual replacement is performed by mem2reg (and in the future
SSAUpdater).
The splitting is divided into four phases. The first phase is an
analysis of the uses of the alloca. This phase recursively walks uses,
building up a dense datastructure representing the ranges of the
alloca's memory actually used and checking for uses which inhibit any
aspects of the transform such as the escape of a pointer.
Once we have a mapping of the ranges of the alloca used by individual
operations, we compute a partitioning of the used ranges. Some uses are
inherently splittable (such as memcpy and memset), while scalar uses are
not splittable. The goal is to build a partitioning that has the minimum
number of splits while placing each unsplittable use in its own
partition. Overlapping unsplittable uses belong to the same partition.
This is the target split of the aggregate alloca, and it maximizes the
number of scalar accesses which become accesses to their own alloca and
candidates for promotion.
Third, we re-walk the uses of the alloca and assign each specific memory
access to all the partitions touched so that we have dense use-lists for
each partition.
Finally, we build a new, smaller alloca for each partition and rewrite
each use of that partition to use the new alloca. During this phase the
pass will also work very hard to transform uses of an alloca into a form
suitable for promotion, including forming vector operations, speculating
loads throguh PHI nodes and selects, etc.
After splitting is complete, each newly refined alloca that is
a candidate for promotion to a scalar SSA value is run through mem2reg.
There are lots of reasonably detailed comments in the source code about
the design and algorithms, and I'm going to be trying to improve them in
subsequent commits to ensure this is well documented, as the new pass is
in many ways more complex than the old one.
Some of this is still a WIP, but the current state is reasonbly stable.
It has passed bootstrap, the nightly test suite, and Duncan has run it
successfully through the ACATS and DragonEgg test suites. That said, it
remains behind a default-off flag until the last few pieces are in
place, and full testing can be done.
Specific areas I'm looking at next:
- Improved comments and some code cleanup from reviews.
- SSAUpdater and enabling this pass inside the CGSCC pass manager.
- Some datastructure tuning and compile-time measurements.
- More aggressive FCA splitting and vector formation.
Many thanks to Duncan Sands for the thorough final review, as well as
Benjamin Kramer for lots of review during the process of writing this
pass, and Daniel Berlin for reviewing the data structures and algorithms
and general theory of the pass. Also, several other people on IRC, over
lunch tables, etc for lots of feedback and advice.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163883 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-14 09:22:59 +00:00
|
|
|
|
2003-05-27 15:52:45 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
2006-10-13 20:53:50 +00:00
|
|
|
// ScalarReplAggregates - Break up alloca's of aggregates into multiple allocas
|
|
|
|
// if possible.
|
2003-05-27 15:52:45 +00:00
|
|
|
//
|
2011-01-14 08:13:00 +00:00
|
|
|
FunctionPass *createScalarReplAggregatesPass(signed Threshold = -1,
|
2012-06-21 13:44:31 +00:00
|
|
|
bool UseDomTree = true,
|
|
|
|
signed StructMemberThreshold = -1,
|
|
|
|
signed ArrayElementThreshold = -1,
|
|
|
|
signed ScalarLoadThreshold = -1);
|
2003-05-27 15:52:45 +00:00
|
|
|
|
2002-05-07 19:37:18 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// InductionVariableSimplify - Transform induction variables in a program to all
|
2003-09-10 05:29:43 +00:00
|
|
|
// use a single canonical induction variable per loop.
|
2002-05-07 19:37:18 +00:00
|
|
|
//
|
2008-10-22 23:32:42 +00:00
|
|
|
Pass *createIndVarSimplifyPass();
|
2002-05-07 19:37:18 +00:00
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// InstructionCombining - Combine instructions to form fewer, simple
|
2006-10-13 20:53:50 +00:00
|
|
|
// instructions. This pass does not modify the CFG, and has a tendency to make
|
|
|
|
// instructions dead, so a subsequent DCE pass is useful.
|
2002-05-07 19:37:18 +00:00
|
|
|
//
|
|
|
|
// This pass combines things like:
|
|
|
|
// %Y = add int 1, %X
|
|
|
|
// %Z = add int 1, %Y
|
|
|
|
// into:
|
|
|
|
// %Z = add int 2, %X
|
|
|
|
//
|
2004-07-27 17:43:21 +00:00
|
|
|
FunctionPass *createInstructionCombiningPass();
|
2002-05-07 19:37:18 +00:00
|
|
|
|
2002-05-10 22:44:16 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
2004-04-18 05:20:32 +00:00
|
|
|
// LICM - This pass is a loop invariant code motion and memory promotion pass.
|
2002-05-10 22:44:16 +00:00
|
|
|
//
|
2008-10-22 23:32:42 +00:00
|
|
|
Pass *createLICMPass();
|
2002-05-10 22:44:16 +00:00
|
|
|
|
2004-10-18 21:08:22 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// LoopStrengthReduce - This pass is strength reduces GEP instructions that use
|
Switch the SCEV expander and LoopStrengthReduce to use
TargetTransformInfo rather than TargetLowering, removing one of the
primary instances of the layering violation of Transforms depending
directly on Target.
This is a really big deal because LSR used to be a "special" pass that
could only be tested fully using llc and by looking at the full output
of it. It also couldn't run with any other loop passes because it had to
be created by the backend. No longer is this true. LSR is now just
a normal pass and we should probably lift the creation of LSR out of
lib/CodeGen/Passes.cpp and into the PassManagerBuilder. =] I've not done
this, or updated all of the tests to use opt and a triple, because
I suspect someone more familiar with LSR would do a better job. This
change should be essentially without functional impact for normal
compilations, and only change behvaior of targetless compilations.
The conversion required changing all of the LSR code to refer to the TTI
interfaces, which fortunately are very similar to TargetLowering's
interfaces. However, it also allowed us to *always* expect to have some
implementation around. I've pushed that simplification through the pass,
and leveraged it to simplify code somewhat. It required some test
updates for one of two things: either we used to skip some checks
altogether but now we get the default "no" answer for them, or we used
to have no information about the target and now we do have some.
I've also started the process of removing AddrMode, as the TTI interface
doesn't use it any longer. In some cases this simplifies code, and in
others it adds some complexity, but I think it's not a bad tradeoff even
there. Subsequent patches will try to clean this up even further and use
other (more appropriate) abstractions.
Yet again, almost all of the formatting changes brought to you by
clang-format. =]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171735 91177308-0d34-0410-b5e6-96231b3b80d8
2013-01-07 14:41:08 +00:00
|
|
|
// a loop's canonical induction variable as one of their indices.
|
2006-03-16 21:53:05 +00:00
|
|
|
//
|
Switch the SCEV expander and LoopStrengthReduce to use
TargetTransformInfo rather than TargetLowering, removing one of the
primary instances of the layering violation of Transforms depending
directly on Target.
This is a really big deal because LSR used to be a "special" pass that
could only be tested fully using llc and by looking at the full output
of it. It also couldn't run with any other loop passes because it had to
be created by the backend. No longer is this true. LSR is now just
a normal pass and we should probably lift the creation of LSR out of
lib/CodeGen/Passes.cpp and into the PassManagerBuilder. =] I've not done
this, or updated all of the tests to use opt and a triple, because
I suspect someone more familiar with LSR would do a better job. This
change should be essentially without functional impact for normal
compilations, and only change behvaior of targetless compilations.
The conversion required changing all of the LSR code to refer to the TTI
interfaces, which fortunately are very similar to TargetLowering's
interfaces. However, it also allowed us to *always* expect to have some
implementation around. I've pushed that simplification through the pass,
and leveraged it to simplify code somewhat. It required some test
updates for one of two things: either we used to skip some checks
altogether but now we get the default "no" answer for them, or we used
to have no information about the target and now we do have some.
I've also started the process of removing AddrMode, as the TTI interface
doesn't use it any longer. In some cases this simplifies code, and in
others it adds some complexity, but I think it's not a bad tradeoff even
there. Subsequent patches will try to clean this up even further and use
other (more appropriate) abstractions.
Yet again, almost all of the formatting changes brought to you by
clang-format. =]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171735 91177308-0d34-0410-b5e6-96231b3b80d8
2013-01-07 14:41:08 +00:00
|
|
|
Pass *createLoopStrengthReducePass();
|
2002-05-10 22:44:16 +00:00
|
|
|
|
2013-06-19 21:07:11 +00:00
|
|
|
Pass *createGlobalMergePass(const TargetMachine *TM = 0);
|
2011-10-17 17:17:43 +00:00
|
|
|
|
2004-04-19 06:28:37 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// LoopUnswitch - This pass is a simple loop unswitching pass.
|
|
|
|
//
|
2008-10-22 23:32:42 +00:00
|
|
|
Pass *createLoopUnswitchPass(bool OptimizeForSize = false);
|
2004-04-19 06:28:37 +00:00
|
|
|
|
2011-01-03 00:25:16 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// LoopInstSimplify - This pass simplifies instructions in a loop's body.
|
|
|
|
//
|
|
|
|
Pass *createLoopInstSimplifyPass();
|
|
|
|
|
2004-04-18 05:20:32 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// LoopUnroll - This pass is a simple loop unrolling pass.
|
|
|
|
//
|
2013-11-05 00:08:03 +00:00
|
|
|
Pass *createLoopUnrollPass(int Threshold = -1, int Count = -1,
|
|
|
|
int AllowPartial = -1, int Runtime = -1);
|
2014-03-31 23:23:51 +00:00
|
|
|
// Create an unrolling pass for full unrolling only.
|
|
|
|
Pass *createSimpleLoopUnrollPass();
|
2004-04-18 05:20:32 +00:00
|
|
|
|
2013-11-16 23:59:05 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// LoopReroll - This pass is a simple loop rerolling pass.
|
|
|
|
//
|
|
|
|
Pass *createLoopRerollPass();
|
|
|
|
|
2007-04-07 01:25:15 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// LoopRotate - This pass is a simple loop rotating pass.
|
|
|
|
//
|
2008-10-22 23:32:42 +00:00
|
|
|
Pass *createLoopRotatePass();
|
2007-04-07 01:25:15 +00:00
|
|
|
|
2010-12-26 19:32:44 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// LoopIdiom - This pass recognizes and replaces idioms in loops.
|
|
|
|
//
|
|
|
|
Pass *createLoopIdiomPass();
|
|
|
|
|
2007-08-07 00:25:56 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
2002-05-07 19:37:18 +00:00
|
|
|
//
|
2006-10-13 20:53:50 +00:00
|
|
|
// PromoteMemoryToRegister - This pass is used to promote memory references to
|
|
|
|
// be register references. A simple example of the transformation performed by
|
|
|
|
// this pass is:
|
2002-05-07 19:37:18 +00:00
|
|
|
//
|
|
|
|
// FROM CODE TO CODE
|
2009-06-14 23:30:43 +00:00
|
|
|
// %X = alloca i32, i32 1 ret i32 42
|
|
|
|
// store i32 42, i32 *%X
|
|
|
|
// %Y = load i32* %X
|
|
|
|
// ret i32 %Y
|
2002-05-07 19:37:18 +00:00
|
|
|
//
|
2005-03-28 02:01:12 +00:00
|
|
|
FunctionPass *createPromoteMemoryToRegisterPass();
|
2002-05-07 19:37:18 +00:00
|
|
|
|
2005-11-10 01:58:38 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
2006-10-13 20:53:50 +00:00
|
|
|
// DemoteRegisterToMemoryPass - This pass is used to demote registers to memory
|
|
|
|
// references. In basically undoes the PromoteMemoryToRegister pass to make cfg
|
|
|
|
// hacking easier.
|
|
|
|
//
|
2005-11-10 01:58:38 +00:00
|
|
|
FunctionPass *createDemoteRegisterToMemoryPass();
|
2010-08-06 18:33:48 +00:00
|
|
|
extern char &DemoteRegisterToMemoryID;
|
2002-05-07 19:37:18 +00:00
|
|
|
|
2002-05-08 22:19:01 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
2006-10-13 20:53:50 +00:00
|
|
|
// Reassociate - This pass reassociates commutative expressions in an order that
|
|
|
|
// is designed to promote better constant propagation, GCSE, LICM, PRE...
|
2002-05-08 22:19:01 +00:00
|
|
|
//
|
|
|
|
// For example: 4 + (x + 5) -> x + (4 + 5)
|
|
|
|
//
|
2003-11-07 17:19:39 +00:00
|
|
|
FunctionPass *createReassociatePass();
|
2002-05-08 22:19:01 +00:00
|
|
|
|
2002-05-21 20:04:15 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
2008-04-20 20:35:01 +00:00
|
|
|
// JumpThreading - Thread control through mult-pred/multi-succ blocks where some
|
|
|
|
// preds always go to some succ.
|
|
|
|
//
|
|
|
|
FunctionPass *createJumpThreadingPass();
|
|
|
|
|
2008-05-14 00:43:10 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
2008-04-20 20:35:01 +00:00
|
|
|
//
|
2006-10-13 20:53:50 +00:00
|
|
|
// CFGSimplification - Merge basic blocks, eliminate unreachable blocks,
|
2002-05-21 20:04:15 +00:00
|
|
|
// simplify terminator instructions, etc...
|
|
|
|
//
|
2013-08-06 02:43:45 +00:00
|
|
|
FunctionPass *createCFGSimplificationPass();
|
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// FlattenCFG - flatten CFG, reduce number of conditional branches by using
|
|
|
|
// parallel-and and parallel-or mode, etc...
|
|
|
|
//
|
|
|
|
FunctionPass *createFlattenCFGPass();
|
2002-05-21 20:04:15 +00:00
|
|
|
|
2013-06-19 20:18:24 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// CFG Structurization - Remove irreducible control flow
|
|
|
|
//
|
|
|
|
Pass *createStructurizeCFGPass();
|
|
|
|
|
2002-09-24 00:08:37 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
2006-10-13 20:53:50 +00:00
|
|
|
// BreakCriticalEdges - Break all of the critical edges in the CFG by inserting
|
|
|
|
// a dummy basic block. This pass may be "required" by passes that cannot deal
|
|
|
|
// with critical edges. For this usage, a pass must call:
|
2002-09-24 15:42:27 +00:00
|
|
|
//
|
|
|
|
// AU.addRequiredID(BreakCriticalEdgesID);
|
|
|
|
//
|
|
|
|
// This pass obviously invalidates the CFG, but can update forward dominator
|
2003-11-10 04:09:44 +00:00
|
|
|
// (set, immediate dominators, tree, and frontier) information.
|
2002-09-24 00:08:37 +00:00
|
|
|
//
|
2004-07-31 10:02:24 +00:00
|
|
|
FunctionPass *createBreakCriticalEdgesPass();
|
2010-08-06 18:33:48 +00:00
|
|
|
extern char &BreakCriticalEdgesID;
|
2002-05-21 20:04:15 +00:00
|
|
|
|
2002-09-26 16:17:33 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
2006-10-13 20:53:50 +00:00
|
|
|
// LoopSimplify - Insert Pre-header blocks into the CFG for every function in
|
|
|
|
// the module. This pass updates dominator information, loop information, and
|
|
|
|
// does not add critical edges to the CFG.
|
2002-09-26 16:17:33 +00:00
|
|
|
//
|
2003-10-12 21:52:28 +00:00
|
|
|
// AU.addRequiredID(LoopSimplifyID);
|
2002-09-26 16:17:33 +00:00
|
|
|
//
|
2009-09-28 14:37:51 +00:00
|
|
|
Pass *createLoopSimplifyPass();
|
2010-08-06 18:33:48 +00:00
|
|
|
extern char &LoopSimplifyID;
|
2002-09-26 16:17:33 +00:00
|
|
|
|
2003-04-23 16:24:19 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
2006-10-13 20:53:50 +00:00
|
|
|
// TailCallElimination - This pass eliminates call instructions to the current
|
|
|
|
// function which occur immediately before return instructions.
|
2006-05-02 04:24:36 +00:00
|
|
|
//
|
|
|
|
FunctionPass *createTailCallEliminationPass();
|
2002-07-23 19:37:38 +00:00
|
|
|
|
2004-03-30 18:41:10 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
2006-10-13 20:53:50 +00:00
|
|
|
//
|
|
|
|
// LowerSwitch - This pass converts SwitchInst instructions into a sequence of
|
|
|
|
// chained binary branch instructions.
|
2004-03-30 18:41:10 +00:00
|
|
|
//
|
2006-05-02 04:24:36 +00:00
|
|
|
FunctionPass *createLowerSwitchPass();
|
2010-08-06 18:33:48 +00:00
|
|
|
extern char &LowerSwitchID;
|
2003-10-05 19:15:13 +00:00
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
2006-10-13 20:53:50 +00:00
|
|
|
//
|
2014-03-20 19:54:47 +00:00
|
|
|
// LowerInvoke - This pass removes invoke instructions, converting them to call
|
|
|
|
// instructions.
|
|
|
|
//
|
|
|
|
FunctionPass *createLowerInvokePass();
|
2010-08-06 18:33:48 +00:00
|
|
|
extern char &LowerInvokePassID;
|
2003-10-05 19:15:13 +00:00
|
|
|
|
2006-05-26 13:58:26 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
2006-10-13 20:53:50 +00:00
|
|
|
//
|
|
|
|
// LCSSA - This pass inserts phi nodes at loop boundaries to simplify other loop
|
2006-05-26 13:58:26 +00:00
|
|
|
// optimizations.
|
2006-10-13 20:53:50 +00:00
|
|
|
//
|
2008-10-22 23:32:42 +00:00
|
|
|
Pass *createLCSSAPass();
|
2010-08-06 18:33:48 +00:00
|
|
|
extern char &LCSSAID;
|
2006-05-26 13:58:26 +00:00
|
|
|
|
2011-01-02 21:47:05 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// EarlyCSE - This pass performs a simple and fast CSE pass over the dominator
|
|
|
|
// tree.
|
|
|
|
//
|
|
|
|
FunctionPass *createEarlyCSEPass();
|
|
|
|
|
2007-07-24 17:55:58 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// GVN - This pass performs global value numbering and redundant load
|
|
|
|
// elimination cotemporaneously.
|
|
|
|
//
|
2010-02-28 05:34:05 +00:00
|
|
|
FunctionPass *createGVNPass(bool NoLoads = false);
|
2007-07-24 17:55:58 +00:00
|
|
|
|
2008-04-09 08:23:16 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// MemCpyOpt - This pass performs optimizations related to eliminating memcpy
|
|
|
|
// calls and/or combining multiple stores into memset's.
|
|
|
|
//
|
|
|
|
FunctionPass *createMemCpyOptPass();
|
|
|
|
|
2008-04-29 00:38:34 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
2008-04-29 20:06:54 +00:00
|
|
|
// LoopDeletion - This pass performs DCE of non-infinite loops that it
|
2008-04-29 00:38:34 +00:00
|
|
|
// can prove are dead.
|
|
|
|
//
|
2008-10-22 23:32:42 +00:00
|
|
|
Pass *createLoopDeletionPass();
|
2008-05-01 06:25:24 +00:00
|
|
|
|
2014-01-25 02:02:55 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// ConstantHoisting - This pass prepares a function for expensive constants.
|
|
|
|
//
|
|
|
|
FunctionPass *createConstantHoistingPass();
|
|
|
|
|
2008-08-23 06:07:02 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// InstructionNamer - Give any unnamed non-void instructions "tmp" names.
|
|
|
|
//
|
|
|
|
FunctionPass *createInstructionNamerPass();
|
2010-08-06 18:33:48 +00:00
|
|
|
extern char &InstructionNamerID;
|
2008-08-23 06:07:02 +00:00
|
|
|
|
2010-05-07 15:40:13 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// Sink - Code Sinking
|
|
|
|
//
|
|
|
|
FunctionPass *createSinkingPass();
|
|
|
|
|
2010-08-03 16:19:16 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// LowerAtomic - Lower atomic intrinsics to non-atomic form
|
|
|
|
//
|
|
|
|
Pass *createLowerAtomicPass();
|
|
|
|
|
2010-08-27 23:31:36 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// ValuePropagation - Propagate CFG-derived value information
|
|
|
|
//
|
2010-08-31 07:48:34 +00:00
|
|
|
Pass *createCorrelatedValuePropagationPass();
|
2010-08-27 23:31:36 +00:00
|
|
|
|
2010-12-20 20:54:37 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// InstructionSimplifier - Remove redundant instructions.
|
|
|
|
//
|
|
|
|
FunctionPass *createInstructionSimplifierPass();
|
|
|
|
extern char &InstructionSimplifierID;
|
|
|
|
|
2011-07-06 18:22:43 +00:00
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
2013-03-14 01:26:17 +00:00
|
|
|
// LowerExpectIntrinsics - Removes llvm.expect intrinsics and creates
|
2011-07-06 18:22:43 +00:00
|
|
|
// "block_weights" metadata.
|
|
|
|
FunctionPass *createLowerExpectIntrinsicPass();
|
|
|
|
|
|
|
|
|
2013-08-23 10:27:02 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// PartiallyInlineLibCalls - Tries to inline the fast path of library
|
|
|
|
// calls such as sqrt.
|
|
|
|
//
|
|
|
|
FunctionPass *createPartiallyInlineLibCallsPass();
|
|
|
|
|
SampleProfileLoader pass. Initial setup.
This adds a new scalar pass that reads a file with samples generated
by 'perf' during runtime. The samples read from the profile are
incorporated and emmited as IR metadata reflecting that profile.
The profile file is assumed to have been generated by an external
profile source. The profile information is converted into IR metadata,
which is later used by the analysis routines to estimate block
frequencies, edge weights and other related data.
External profile information files have no fixed format, each profiler
is free to define its own. This includes both the on-disk representation
of the profile and the kind of profile information stored in the file.
A common kind of profile is based on sampling (e.g., perf), which
essentially counts how many times each line of the program has been
executed during the run.
The SampleProfileLoader pass is organized as a scalar transformation.
On startup, it reads the file given in -sample-profile-file to
determine what kind of profile it contains. This file is assumed to
contain profile information for the whole application. The profile
data in the file is read and incorporated into the internal state of
the corresponding profiler.
To facilitate testing, I've organized the profilers to support two file
formats: text and native. The native format is whatever on-disk
representation the profiler wants to support, I think this will mostly
be bitcode files, but it could be anything the profiler wants to
support. To do this, every profiler must implement the
SampleProfile::loadNative() function.
The text format is mostly meant for debugging. Records are separated by
newlines, but each profiler is free to interpret records as it sees fit.
Profilers must implement the SampleProfile::loadText() function.
Finally, the pass will call SampleProfile::emitAnnotations() for each
function in the current translation unit. This function needs to
translate the loaded profile into IR metadata, which the analyzer will
later be able to use.
This patch implements the first steps towards the above design. I've
implemented a sample-based flat profiler. The format of the profile is
fairly simplistic. Each sampled function contains a list of relative
line locations (from the start of the function) together with a count
representing how many samples were collected at that line during
execution. I generate this profile using perf and a separate converter
tool.
Currently, I have only implemented a text format for these profiles. I
am interested in initial feedback to the whole approach before I send
the other parts of the implementation for review.
This patch implements:
- The SampleProfileLoader pass.
- The base ExternalProfile class with the core interface.
- A SampleProfile sub-class using the above interface. The profiler
generates branch weight metadata on every branch instructions that
matches the profiles.
- A text loader class to assist the implementation of
SampleProfile::loadText().
- Basic unit tests for the pass.
Additionally, the patch uses profile information to compute branch
weights based on instruction samples.
This patch converts instruction samples into branch weights. It
does a fairly simplistic conversion:
Given a multi-way branch instruction, it calculates the weight of
each branch based on the maximum sample count gathered from each
target basic block.
Note that this assignment of branch weights is somewhat lossy and can be
misleading. If a basic block has more than one incoming branch, all the
incoming branches will get the same weight. In reality, it may be that
only one of them is the most heavily taken branch.
I will adjust this assignment in subsequent patches.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194566 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-13 12:22:21 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// SampleProfilePass - Loads sample profile data from disk and generates
|
|
|
|
// IR metadata to reflect the profile.
|
|
|
|
FunctionPass *createSampleProfileLoaderPass();
|
|
|
|
FunctionPass *createSampleProfileLoaderPass(StringRef Name);
|
|
|
|
|
2013-11-22 16:58:05 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// ScalarizerPass - Converts vector operations into scalar operations
|
|
|
|
//
|
|
|
|
FunctionPass *createScalarizerPass();
|
|
|
|
|
2014-03-03 20:06:11 +00:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// AddDiscriminators - Add DWARF path discriminators to the IR.
|
|
|
|
FunctionPass *createAddDiscriminatorsPass();
|
|
|
|
|
2003-11-11 22:41:34 +00:00
|
|
|
} // End llvm namespace
|
|
|
|
|
2002-05-07 19:37:18 +00:00
|
|
|
#endif
|