2010-10-07 04:17:38 +00:00
|
|
|
//===- llvm/InitializePasses.h -------- Initialize All Passes ---*- C++ -*-===//
|
|
|
|
|
//
|
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
|
//
|
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
|
//
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
//
|
|
|
|
|
// This file contains the declarations for the pass initialization routines
|
|
|
|
|
// for the entire LLVM project.
|
|
|
|
|
//
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
|
|
#ifndef LLVM_INITIALIZEPASSES_H
|
|
|
|
|
#define LLVM_INITIALIZEPASSES_H
|
|
|
|
|
|
|
|
|
|
namespace llvm {
|
|
|
|
|
|
|
|
|
|
class PassRegistry;
|
|
|
|
|
|
2011-01-29 01:09:53 +00:00
|
|
|
/// initializeCore - Initialize all passes linked into the
|
2010-10-07 19:51:21 +00:00
|
|
|
/// TransformUtils library.
|
|
|
|
|
void initializeCore(PassRegistry&);
|
|
|
|
|
|
2011-01-29 01:09:53 +00:00
|
|
|
/// initializeTransformUtils - Initialize all passes linked into the
|
2010-10-07 17:55:47 +00:00
|
|
|
/// TransformUtils library.
|
|
|
|
|
void initializeTransformUtils(PassRegistry&);
|
|
|
|
|
|
2011-01-29 01:09:53 +00:00
|
|
|
/// initializeScalarOpts - Initialize all passes linked into the
|
2010-10-07 17:55:47 +00:00
|
|
|
/// ScalarOpts library.
|
|
|
|
|
void initializeScalarOpts(PassRegistry&);
|
|
|
|
|
|
2013-01-28 01:35:51 +00:00
|
|
|
/// initializeObjCARCOpts - Initialize all passes linked into the ObjCARCOpts
|
|
|
|
|
/// library.
|
|
|
|
|
void initializeObjCARCOpts(PassRegistry&);
|
|
|
|
|
|
2012-02-01 03:51:43 +00:00
|
|
|
/// initializeVectorization - Initialize all passes linked into the
|
|
|
|
|
/// Vectorize library.
|
|
|
|
|
void initializeVectorization(PassRegistry&);
|
|
|
|
|
|
2011-01-29 01:09:53 +00:00
|
|
|
/// initializeInstCombine - Initialize all passes linked into the
|
2015-01-20 22:44:35 +00:00
|
|
|
/// InstCombine library.
|
2010-10-07 20:04:55 +00:00
|
|
|
void initializeInstCombine(PassRegistry&);
|
|
|
|
|
|
2010-10-07 18:09:59 +00:00
|
|
|
/// initializeIPO - Initialize all passes linked into the IPO library.
|
|
|
|
|
void initializeIPO(PassRegistry&);
|
|
|
|
|
|
2010-10-07 20:17:24 +00:00
|
|
|
/// initializeInstrumentation - Initialize all passes linked into the
|
|
|
|
|
/// Instrumentation library.
|
|
|
|
|
void initializeInstrumentation(PassRegistry&);
|
|
|
|
|
|
2010-10-07 18:31:00 +00:00
|
|
|
/// initializeAnalysis - Initialize all passes linked into the Analysis library.
|
|
|
|
|
void initializeAnalysis(PassRegistry&);
|
|
|
|
|
|
|
|
|
|
/// initializeIPA - Initialize all passes linked into the IPA library.
|
|
|
|
|
void initializeIPA(PassRegistry&);
|
|
|
|
|
|
2010-10-07 18:41:20 +00:00
|
|
|
/// initializeCodeGen - Initialize all passes linked into the CodeGen library.
|
|
|
|
|
void initializeCodeGen(PassRegistry&);
|
|
|
|
|
|
2010-10-07 18:50:11 +00:00
|
|
|
/// initializeCodeGen - Initialize all passes linked into the CodeGen library.
|
|
|
|
|
void initializeTarget(PassRegistry&);
|
|
|
|
|
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeAAEvalPass(PassRegistry&);
|
2014-03-03 20:06:11 +00:00
|
|
|
void initializeAddDiscriminatorsPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeADCEPass(PassRegistry&);
|
[BDCE] Add a bit-tracking DCE pass
BDCE is a bit-tracking dead code elimination pass. It is based on ADCE (the
"aggressive DCE" pass), with the added capability to track dead bits of integer
valued instructions and remove those instructions when all of the bits are
dead.
Currently, it does not actually do this all-bits-dead removal, but rather
replaces the instruction's uses with a constant zero, and lets instcombine (and
the later run of ADCE) do the rest. Because we essentially get a run of ADCE
"for free" while tracking the dead bits, we also do what ADCE does and removes
actually-dead instructions as well (this includes instructions newly trivially
dead because all bits were dead, but not all such instructions can be removed).
The motivation for this is a case like:
int __attribute__((const)) foo(int i);
int bar(int x) {
x |= (4 & foo(5));
x |= (8 & foo(3));
x |= (16 & foo(2));
x |= (32 & foo(1));
x |= (64 & foo(0));
x |= (128& foo(4));
return x >> 4;
}
As it turns out, if you order the bit-field insertions so that all of the dead
ones come last, then instcombine will remove them. However, if you pick some
other order (such as the one above), the fact that some of the calls to foo()
are useless is not locally obvious, and we don't remove them (without this
pass).
I did a quick compile-time overhead check using sqlite from the test suite
(Release+Asserts). BDCE took ~0.4% of the compilation time (making it about
twice as expensive as ADCE).
I've not looked at why yet, but we eliminate instructions due to having
all-dead bits in:
External/SPEC/CFP2006/447.dealII/447.dealII
External/SPEC/CINT2006/400.perlbench/400.perlbench
External/SPEC/CINT2006/403.gcc/403.gcc
MultiSource/Applications/ClamAV/clamscan
MultiSource/Benchmarks/7zip/7zip-benchmark
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229462 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-17 01:36:59 +00:00
|
|
|
void initializeBDCEPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeAliasAnalysisAnalysisGroup(PassRegistry&);
|
|
|
|
|
void initializeAliasAnalysisCounterPass(PassRegistry&);
|
|
|
|
|
void initializeAliasDebuggerPass(PassRegistry&);
|
|
|
|
|
void initializeAliasSetPrinterPass(PassRegistry&);
|
|
|
|
|
void initializeAlwaysInlinerPass(PassRegistry&);
|
|
|
|
|
void initializeArgPromotionPass(PassRegistry&);
|
2014-08-21 21:50:01 +00:00
|
|
|
void initializeAtomicExpandPass(PassRegistry&);
|
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
|
|
|
void initializeSampleProfileLoaderPass(PassRegistry&);
|
2014-09-07 20:05:11 +00:00
|
|
|
void initializeAlignmentFromAssumptionsPass(PassRegistry&);
|
Introduce a BarrierNoop pass, a hack designed to allow *some* control
over the implicitly-formed-and-nesting CGSCC pass manager and function
pass managers, especially when using them on the opt commandline or
using extension points in the module builder. The '-barrier' opt flag
(or the pass itself) will create a no-op module pass in the pipeline,
resetting the pass manager stack, and allowing the creation of a new
pipeline of function passes or CGSCC passes to be created that is
independent from any previous pipelines.
For example, this can be used to test running two CGSCC passes in
independent CGSCC pass managers as opposed to in the same CGSCC pass
manager. It also allows us to introduce a further hack into the
PassManagerBuilder to separate the O0 pipeline extension passes from the
always-inliner's CGSCC pass manager, which they likely do not want to
participate in... At the very least none of the Sanitizer passes want
this behavior.
This fixes a bug with ASan at O0 currently, and I'll commit the ASan
test which covers this pass. I'm happy to add a test case that this pass
exists and works, but not sure how much time folks would like me to
spend adding test cases for the details of its behavior of partition
pass managers.... The whole thing is just vile, and mostly intended to
unblock ASan, so I'm hoping to rip this all out in a brave new pass
manager world.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@166172 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-18 08:05:46 +00:00
|
|
|
void initializeBarrierNoopPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeBasicAliasAnalysisPass(PassRegistry&);
|
2013-11-26 04:19:30 +00:00
|
|
|
void initializeCallGraphWrapperPassPass(PassRegistry &);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeBlockExtractorPassPass(PassRegistry&);
|
2011-07-25 19:25:40 +00:00
|
|
|
void initializeBlockFrequencyInfoPass(PassRegistry&);
|
2012-05-22 17:19:09 +00:00
|
|
|
void initializeBoundsCheckingPass(PassRegistry&);
|
2012-02-08 21:22:48 +00:00
|
|
|
void initializeBranchFolderPassPass(PassRegistry&);
|
2011-06-04 01:16:30 +00:00
|
|
|
void initializeBranchProbabilityInfoPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeBreakCriticalEdgesPass(PassRegistry&);
|
2013-01-11 17:28:14 +00:00
|
|
|
void initializeCallGraphPrinterPass(PassRegistry&);
|
|
|
|
|
void initializeCallGraphViewerPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeCFGOnlyPrinterPass(PassRegistry&);
|
|
|
|
|
void initializeCFGOnlyViewerPass(PassRegistry&);
|
|
|
|
|
void initializeCFGPrinterPass(PassRegistry&);
|
2013-08-06 02:43:45 +00:00
|
|
|
void initializeCFGSimplifyPassPass(PassRegistry&);
|
2014-09-02 21:43:13 +00:00
|
|
|
void initializeCFLAliasAnalysisPass(PassRegistry&);
|
2014-11-11 21:08:02 +00:00
|
|
|
void initializeForwardControlFlowIntegrityPass(PassRegistry&);
|
2013-08-06 02:43:45 +00:00
|
|
|
void initializeFlattenCFGPassPass(PassRegistry&);
|
2013-06-19 20:18:24 +00:00
|
|
|
void initializeStructurizeCFGPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeCFGViewerPass(PassRegistry&);
|
2014-01-25 02:02:55 +00:00
|
|
|
void initializeConstantHoistingPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeCodeGenPreparePass(PassRegistry&);
|
|
|
|
|
void initializeConstantMergePass(PassRegistry&);
|
|
|
|
|
void initializeConstantPropagationPass(PassRegistry&);
|
2012-01-07 03:02:36 +00:00
|
|
|
void initializeMachineCopyPropagationPass(PassRegistry&);
|
2012-11-02 21:48:17 +00:00
|
|
|
void initializeCostModelAnalysisPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeCorrelatedValuePropagationPass(PassRegistry&);
|
|
|
|
|
void initializeDAEPass(PassRegistry&);
|
|
|
|
|
void initializeDAHPass(PassRegistry&);
|
|
|
|
|
void initializeDCEPass(PassRegistry&);
|
|
|
|
|
void initializeDSEPass(PassRegistry&);
|
2014-04-15 16:27:38 +00:00
|
|
|
void initializeDebugInfoVerifierLegacyPassPass(PassRegistry &);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeDeadInstEliminationPass(PassRegistry&);
|
|
|
|
|
void initializeDeadMachineInstructionElimPass(PassRegistry&);
|
2013-11-12 22:47:20 +00:00
|
|
|
void initializeDelinearizationPass(PassRegistry &);
|
dependence analysis
Patch from Preston Briggs <preston.briggs@gmail.com>.
This is an updated version of the dependence-analysis patch, including an MIV
test based on Banerjee's inequalities.
It's a fairly complete implementation of the paper
Practical Dependence Testing
Gina Goff, Ken Kennedy, and Chau-Wen Tseng
PLDI 1991
It cannot yet propagate constraints between coupled RDIV subscripts (discussed
in Section 5.3.2 of the paper).
It's organized as a FunctionPass with a single entry point that supports testing
for dependence between two instructions in a function. If there's no dependence,
it returns null. If there's a dependence, it returns a pointer to a Dependence
which can be queried about details (what kind of dependence, is it loop
independent, direction and distance vector entries, etc). I haven't included
every imaginable feature, but there's a good selection that should be adequate
for supporting many loop transformations. Of course, it can be extended as
necessary.
Included in the patch file are many test cases, commented with C code showing
the loops and array references.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165708 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-11 07:32:34 +00:00
|
|
|
void initializeDependenceAnalysisPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeDomOnlyPrinterPass(PassRegistry&);
|
|
|
|
|
void initializeDomOnlyViewerPass(PassRegistry&);
|
|
|
|
|
void initializeDomPrinterPass(PassRegistry&);
|
|
|
|
|
void initializeDomViewerPass(PassRegistry&);
|
|
|
|
|
void initializeDominanceFrontierPass(PassRegistry&);
|
2014-01-13 13:07:17 +00:00
|
|
|
void initializeDominatorTreeWrapperPassPass(PassRegistry&);
|
2012-07-04 00:09:54 +00:00
|
|
|
void initializeEarlyIfConverterPass(PassRegistry&);
|
2011-01-04 21:10:05 +00:00
|
|
|
void initializeEdgeBundlesPass(PassRegistry&);
|
2012-02-08 21:23:13 +00:00
|
|
|
void initializeExpandPostRAPass(PassRegistry&);
|
2011-04-16 01:20:23 +00:00
|
|
|
void initializeGCOVProfilerPass(PassRegistry&);
|
2014-12-08 18:02:35 +00:00
|
|
|
void initializeInstrProfilingPass(PassRegistry&);
|
2011-11-16 01:35:23 +00:00
|
|
|
void initializeAddressSanitizerPass(PassRegistry&);
|
2012-11-28 10:31:36 +00:00
|
|
|
void initializeAddressSanitizerModulePass(PassRegistry&);
|
2012-11-29 09:57:20 +00:00
|
|
|
void initializeMemorySanitizerPass(PassRegistry&);
|
2012-02-13 22:50:51 +00:00
|
|
|
void initializeThreadSanitizerPass(PassRegistry&);
|
2014-11-11 22:14:37 +00:00
|
|
|
void initializeSanitizerCoverageModulePass(PassRegistry&);
|
2013-08-07 22:47:18 +00:00
|
|
|
void initializeDataFlowSanitizerPass(PassRegistry&);
|
2013-11-22 16:58:05 +00:00
|
|
|
void initializeScalarizerPass(PassRegistry&);
|
2015-01-27 01:34:14 +00:00
|
|
|
void initializeEarlyCSELegacyPassPass(PassRegistry &);
|
2010-11-18 18:45:06 +00:00
|
|
|
void initializeExpandISelPseudosPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeFunctionAttrsPass(PassRegistry&);
|
2012-02-08 21:23:13 +00:00
|
|
|
void initializeGCMachineCodeAnalysisPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeGCModuleInfoPass(PassRegistry&);
|
|
|
|
|
void initializeGVNPass(PassRegistry&);
|
|
|
|
|
void initializeGlobalDCEPass(PassRegistry&);
|
|
|
|
|
void initializeGlobalOptPass(PassRegistry&);
|
|
|
|
|
void initializeGlobalsModRefPass(PassRegistry&);
|
|
|
|
|
void initializeIPCPPass(PassRegistry&);
|
|
|
|
|
void initializeIPSCCPPass(PassRegistry&);
|
|
|
|
|
void initializeIVUsersPass(PassRegistry&);
|
|
|
|
|
void initializeIfConverterPass(PassRegistry&);
|
2015-01-16 01:03:22 +00:00
|
|
|
void initializeInductiveRangeCheckEliminationPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeIndVarSimplifyPass(PassRegistry&);
|
2013-01-21 11:39:18 +00:00
|
|
|
void initializeInlineCostAnalysisPass(PassRegistry&);
|
2015-01-20 22:44:35 +00:00
|
|
|
void initializeInstructionCombiningPassPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeInstCountPass(PassRegistry&);
|
|
|
|
|
void initializeInstNamerPass(PassRegistry&);
|
|
|
|
|
void initializeInternalizePassPass(PassRegistry&);
|
|
|
|
|
void initializeIntervalPartitionPass(PassRegistry&);
|
2014-06-05 19:29:43 +00:00
|
|
|
void initializeJumpInstrTableInfoPass(PassRegistry&);
|
|
|
|
|
void initializeJumpInstrTablesPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeJumpThreadingPass(PassRegistry&);
|
|
|
|
|
void initializeLCSSAPass(PassRegistry&);
|
|
|
|
|
void initializeLICMPass(PassRegistry&);
|
|
|
|
|
void initializeLazyValueInfoPass(PassRegistry&);
|
|
|
|
|
void initializeLibCallAliasAnalysisPass(PassRegistry&);
|
|
|
|
|
void initializeLintPass(PassRegistry&);
|
2010-11-30 02:17:10 +00:00
|
|
|
void initializeLiveDebugVariablesPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeLiveIntervalsPass(PassRegistry&);
|
2012-06-09 02:13:10 +00:00
|
|
|
void initializeLiveRegMatrixPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeLiveStacksPass(PassRegistry&);
|
|
|
|
|
void initializeLiveVariablesPass(PassRegistry&);
|
|
|
|
|
void initializeLoaderPassPass(PassRegistry&);
|
2012-02-08 21:23:13 +00:00
|
|
|
void initializeLocalStackSlotPassPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeLoopDeletionPass(PassRegistry&);
|
|
|
|
|
void initializeLoopExtractorPass(PassRegistry&);
|
2015-01-17 14:16:18 +00:00
|
|
|
void initializeLoopInfoWrapperPassPass(PassRegistry&);
|
2011-01-03 00:25:16 +00:00
|
|
|
void initializeLoopInstSimplifyPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeLoopRotatePass(PassRegistry&);
|
|
|
|
|
void initializeLoopSimplifyPass(PassRegistry&);
|
|
|
|
|
void initializeLoopStrengthReducePass(PassRegistry&);
|
2011-10-17 17:17:43 +00:00
|
|
|
void initializeGlobalMergePass(PassRegistry&);
|
2013-11-16 23:59:05 +00:00
|
|
|
void initializeLoopRerollPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeLoopUnrollPass(PassRegistry&);
|
|
|
|
|
void initializeLoopUnswitchPass(PassRegistry&);
|
2010-12-26 19:32:44 +00:00
|
|
|
void initializeLoopIdiomRecognizePass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeLowerAtomicPass(PassRegistry&);
|
2015-02-20 20:30:47 +00:00
|
|
|
void initializeLowerBitSetsPass(PassRegistry&);
|
2011-07-06 18:22:43 +00:00
|
|
|
void initializeLowerExpectIntrinsicPass(PassRegistry&);
|
2010-10-19 17:21:58 +00:00
|
|
|
void initializeLowerIntrinsicsPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeLowerInvokePass(PassRegistry&);
|
|
|
|
|
void initializeLowerSwitchPass(PassRegistry&);
|
2011-07-25 19:25:40 +00:00
|
|
|
void initializeMachineBlockFrequencyInfoPass(PassRegistry&);
|
Implement a block placement pass based on the branch probability and
block frequency analyses. This differs substantially from the existing
block-placement pass in LLVM:
1) It operates on the Machine-IR in the CodeGen layer. This exposes much
more (and more precise) information and opportunities. Also, the
results are more stable due to fewer transforms ocurring after the
pass runs.
2) It uses the generalized probability and frequency analyses. These can
model static heuristics, code annotation derived heuristics as well
as eventual profile loading. By basing the optimization on the
analysis interface it can work from any (or a combination) of these
inputs.
3) It uses a more aggressive algorithm, both building chains from tho
bottom up to maximize benefit, and using an SCC-based walk to layout
chains of blocks in a profitable ordering without O(N^2) iterations
which the old pass involves.
The pass is currently gated behind a flag, and not enabled by default
because it still needs to grow some important features. Most notably, it
needs to support loop aligning and careful layout of loop structures
much as done by hand currently in CodePlacementOpt. Once it supports
these, and has sufficient testing and quality tuning, it should replace
both of these passes.
Thanks to Nick Lewycky and Richard Smith for help authoring & debugging
this, and to Jakob, Andy, Eric, Jim, and probably a few others I'm
forgetting for reviewing and answering all my questions. Writing
a backend pass is *sooo* much better now than it used to be. =D
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142641 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-21 06:46:38 +00:00
|
|
|
void initializeMachineBlockPlacementPass(PassRegistry&);
|
2011-11-02 07:17:12 +00:00
|
|
|
void initializeMachineBlockPlacementStatsPass(PassRegistry&);
|
2011-06-16 20:22:37 +00:00
|
|
|
void initializeMachineBranchProbabilityInfoPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeMachineCSEPass(PassRegistry&);
|
|
|
|
|
void initializeMachineDominatorTreePass(PassRegistry&);
|
2014-07-12 21:59:52 +00:00
|
|
|
void initializeMachineDominanceFrontierPass(PassRegistry&);
|
2012-09-17 14:08:37 +00:00
|
|
|
void initializeMachinePostDominatorTreePass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeMachineLICMPass(PassRegistry&);
|
|
|
|
|
void initializeMachineLoopInfoPass(PassRegistry&);
|
|
|
|
|
void initializeMachineModuleInfoPass(PassRegistry&);
|
2014-07-19 18:29:29 +00:00
|
|
|
void initializeMachineRegionInfoPassPass(PassRegistry&);
|
2012-01-17 06:55:03 +00:00
|
|
|
void initializeMachineSchedulerPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeMachineSinkingPass(PassRegistry&);
|
2012-07-26 18:38:11 +00:00
|
|
|
void initializeMachineTraceMetricsPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeMachineVerifierPassPass(PassRegistry&);
|
|
|
|
|
void initializeMemCpyOptPass(PassRegistry&);
|
|
|
|
|
void initializeMemDepPrinterPass(PassRegistry&);
|
2015-02-06 01:46:42 +00:00
|
|
|
void initializeMemDerefPrinterPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeMemoryDependenceAnalysisPass(PassRegistry&);
|
2014-07-18 19:13:09 +00:00
|
|
|
void initializeMergedLoadStoreMotionPass(PassRegistry &);
|
2012-09-11 02:46:18 +00:00
|
|
|
void initializeMetaRenamerPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeMergeFunctionsPass(PassRegistry&);
|
|
|
|
|
void initializeModuleDebugInfoPrinterPass(PassRegistry&);
|
|
|
|
|
void initializeNoAAPass(PassRegistry&);
|
2011-06-15 23:37:01 +00:00
|
|
|
void initializeObjCARCAliasAnalysisPass(PassRegistry&);
|
2012-01-17 20:52:24 +00:00
|
|
|
void initializeObjCARCAPElimPass(PassRegistry&);
|
2011-06-15 23:37:01 +00:00
|
|
|
void initializeObjCARCExpandPass(PassRegistry&);
|
|
|
|
|
void initializeObjCARCContractPass(PassRegistry&);
|
|
|
|
|
void initializeObjCARCOptPass(PassRegistry&);
|
2014-11-17 02:28:27 +00:00
|
|
|
void initializePAEvalPass(PassRegistry &);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeOptimizePHIsPass(PassRegistry&);
|
2013-08-23 10:27:02 +00:00
|
|
|
void initializePartiallyInlineLibCallsPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializePEIPass(PassRegistry&);
|
|
|
|
|
void initializePHIEliminationPass(PassRegistry&);
|
|
|
|
|
void initializePartialInlinerPass(PassRegistry&);
|
|
|
|
|
void initializePeepholeOptimizerPass(PassRegistry&);
|
|
|
|
|
void initializePostDomOnlyPrinterPass(PassRegistry&);
|
|
|
|
|
void initializePostDomOnlyViewerPass(PassRegistry&);
|
|
|
|
|
void initializePostDomPrinterPass(PassRegistry&);
|
|
|
|
|
void initializePostDomViewerPass(PassRegistry&);
|
|
|
|
|
void initializePostDominatorTreePass(PassRegistry&);
|
2012-02-08 21:23:13 +00:00
|
|
|
void initializePostRASchedulerPass(PassRegistry&);
|
2013-12-28 21:56:51 +00:00
|
|
|
void initializePostMachineSchedulerPass(PassRegistry&);
|
2014-01-12 12:15:39 +00:00
|
|
|
void initializePrintFunctionPassWrapperPass(PassRegistry&);
|
|
|
|
|
void initializePrintModulePassWrapperPass(PassRegistry&);
|
2013-02-08 23:37:41 +00:00
|
|
|
void initializePrintBasicBlockPassPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeProcessImplicitDefsPass(PassRegistry&);
|
|
|
|
|
void initializePromotePassPass(PassRegistry&);
|
|
|
|
|
void initializePruneEHPass(PassRegistry&);
|
|
|
|
|
void initializeReassociatePass(PassRegistry&);
|
|
|
|
|
void initializeRegToMemPass(PassRegistry&);
|
2014-07-19 18:29:29 +00:00
|
|
|
void initializeRegionInfoPassPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeRegionOnlyPrinterPass(PassRegistry&);
|
|
|
|
|
void initializeRegionOnlyViewerPass(PassRegistry&);
|
|
|
|
|
void initializeRegionPrinterPass(PassRegistry&);
|
|
|
|
|
void initializeRegionViewerPass(PassRegistry&);
|
Add a pass for constructing gc.statepoint sequences w/explicit relocations
This patch consists of a single pass whose only purpose is to visit previous inserted gc.statepoints which do not have gc.relocates inserted yet, and insert them. This can be used either immediately after IR generation to perform 'early safepoint insertion' or late in the pass order to perform 'late insertion'.
This patch is setting the stage for work to continue in tree. In particular, there are known naming and style violations in the current patch. I'll try to get those resolved over the next week or so. As I touch each area to make style changes, I need to make sure we have adequate testing in place. As part of the cleanup, I will be cleaning up a collection of test cases we have out of tree and submitting them upstream. The tests included in this change are very basic and mostly to provide examples of usage.
The pass has several main subproblems it needs to address:
- First, it has identify any live pointers. In the current code, the use of address spaces to distinguish pointers to GC managed objects is hard coded, but this will become parametrizable in the near future. Note that the current change doesn't actually contain a useful liveness analysis. It was seperated into a followup change as the code wasn't ready to be shared. Instead, the current implementation just considers any dominating def of appropriate pointer type to be live.
- Second, it has to identify base pointers for each live pointer. This is a fairly straight forward data flow algorithm.
- Third, the information in the previous steps is used to actually introduce rewrites. Rather than trying to do this by hand, we simply re-purpose the code behind Mem2Reg to do this for us.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229945 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-20 01:06:44 +00:00
|
|
|
void initializeRewriteStatepointsForGCPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeSCCPPass(PassRegistry&);
|
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
|
|
|
void initializeSROAPass(PassRegistry&);
|
2011-01-18 03:53:26 +00:00
|
|
|
void initializeSROA_DTPass(PassRegistry&);
|
2011-01-14 08:13:00 +00:00
|
|
|
void initializeSROA_SSAUpPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeScalarEvolutionAliasAnalysisPass(PassRegistry&);
|
|
|
|
|
void initializeScalarEvolutionPass(PassRegistry&);
|
|
|
|
|
void initializeSimpleInlinerPass(PassRegistry&);
|
2015-01-28 19:28:03 +00:00
|
|
|
void initializeShadowStackGCLoweringPass(PassRegistry&);
|
2011-06-26 22:34:10 +00:00
|
|
|
void initializeRegisterCoalescerPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeSingleLoopExtractorPass(PassRegistry&);
|
|
|
|
|
void initializeSinkingPass(PassRegistry&);
|
2014-05-01 18:38:36 +00:00
|
|
|
void initializeSeparateConstOffsetFromGEPPass(PassRegistry &);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeSlotIndexesPass(PassRegistry&);
|
2011-01-06 01:21:53 +00:00
|
|
|
void initializeSpillPlacementPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeStackProtectorPass(PassRegistry&);
|
2012-09-06 09:17:37 +00:00
|
|
|
void initializeStackColoringPass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeStackSlotColoringPass(PassRegistry&);
|
Add straight-line strength reduction to LLVM
Summary:
Straight-line strength reduction (SLSR) is implemented in GCC but not yet in
LLVM. It has proven to effectively simplify statements derived from an unrolled
loop, and can potentially benefit many other cases too. For example,
LLVM unrolls
#pragma unroll
foo (int i = 0; i < 3; ++i) {
sum += foo((b + i) * s);
}
into
sum += foo(b * s);
sum += foo((b + 1) * s);
sum += foo((b + 2) * s);
However, no optimizations yet reduce the internal redundancy of the three
expressions:
b * s
(b + 1) * s
(b + 2) * s
With SLSR, LLVM can optimize these three expressions into:
t1 = b * s
t2 = t1 + s
t3 = t2 + s
This commit is only an initial step towards implementing a series of such
optimizations. I will implement more (see TODO in the file commentary) in the
near future. This optimization is enabled for the NVPTX backend for now.
However, I am more than happy to push it to the standard optimization pipeline
after more thorough performance tests.
Test Plan: test/StraightLineStrengthReduce/slsr.ll
Reviewers: eliben, HaoLiu, meheff, hfinkel, jholewinski, atrick
Reviewed By: jholewinski, atrick
Subscribers: karthikthecool, jholewinski, llvm-commits
Differential Revision: http://reviews.llvm.org/D7310
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228016 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-03 19:37:06 +00:00
|
|
|
void initializeStraightLineStrengthReducePass(PassRegistry &);
|
2010-10-07 04:17:38 +00:00
|
|
|
void initializeStripDeadDebugInfoPass(PassRegistry&);
|
|
|
|
|
void initializeStripDeadPrototypesPassPass(PassRegistry&);
|
|
|
|
|
void initializeStripDebugDeclarePass(PassRegistry&);
|
|
|
|
|
void initializeStripNonDebugSymbolsPass(PassRegistry&);
|
|
|
|
|
void initializeStripSymbolsPass(PassRegistry&);
|
|
|
|
|
void initializeTailCallElimPass(PassRegistry&);
|
2012-02-08 21:23:13 +00:00
|
|
|
void initializeTailDuplicatePassPass(PassRegistry&);
|
2012-02-04 02:56:45 +00:00
|
|
|
void initializeTargetPassConfigPass(PassRegistry&);
|
2014-02-25 17:30:31 +00:00
|
|
|
void initializeDataLayoutPassPass(PassRegistry &);
|
[PM] Change the core design of the TTI analysis to use a polymorphic
type erased interface and a single analysis pass rather than an
extremely complex analysis group.
The end result is that the TTI analysis can contain a type erased
implementation that supports the polymorphic TTI interface. We can build
one from a target-specific implementation or from a dummy one in the IR.
I've also factored all of the code into "mix-in"-able base classes,
including CRTP base classes to facilitate calling back up to the most
specialized form when delegating horizontally across the surface. These
aren't as clean as I would like and I'm planning to work on cleaning
some of this up, but I wanted to start by putting into the right form.
There are a number of reasons for this change, and this particular
design. The first and foremost reason is that an analysis group is
complete overkill, and the chaining delegation strategy was so opaque,
confusing, and high overhead that TTI was suffering greatly for it.
Several of the TTI functions had failed to be implemented in all places
because of the chaining-based delegation making there be no checking of
this. A few other functions were implemented with incorrect delegation.
The message to me was very clear working on this -- the delegation and
analysis group structure was too confusing to be useful here.
The other reason of course is that this is *much* more natural fit for
the new pass manager. This will lay the ground work for a type-erased
per-function info object that can look up the correct subtarget and even
cache it.
Yet another benefit is that this will significantly simplify the
interaction of the pass managers and the TargetMachine. See the future
work below.
The downside of this change is that it is very, very verbose. I'm going
to work to improve that, but it is somewhat an implementation necessity
in C++ to do type erasure. =/ I discussed this design really extensively
with Eric and Hal prior to going down this path, and afterward showed
them the result. No one was really thrilled with it, but there doesn't
seem to be a substantially better alternative. Using a base class and
virtual method dispatch would make the code much shorter, but as
discussed in the update to the programmer's manual and elsewhere,
a polymorphic interface feels like the more principled approach even if
this is perhaps the least compelling example of it. ;]
Ultimately, there is still a lot more to be done here, but this was the
huge chunk that I couldn't really split things out of because this was
the interface change to TTI. I've tried to minimize all the other parts
of this. The follow up work should include at least:
1) Improving the TargetMachine interface by having it directly return
a TTI object. Because we have a non-pass object with value semantics
and an internal type erasure mechanism, we can narrow the interface
of the TargetMachine to *just* do what we need: build and return
a TTI object that we can then insert into the pass pipeline.
2) Make the TTI object be fully specialized for a particular function.
This will include splitting off a minimal form of it which is
sufficient for the inliner and the old pass manager.
3) Add a new pass manager analysis which produces TTI objects from the
target machine for each function. This may actually be done as part
of #2 in order to use the new analysis to implement #2.
4) Work on narrowing the API between TTI and the targets so that it is
easier to understand and less verbose to type erase.
5) Work on narrowing the API between TTI and its clients so that it is
easier to understand and less verbose to forward.
6) Try to improve the CRTP-based delegation. I feel like this code is
just a bit messy and exacerbating the complexity of implementing
the TTI in each target.
Many thanks to Eric and Hal for their help here. I ended up blocked on
this somewhat more abruptly than I expected, and so I appreciate getting
it sorted out very quickly.
Differential Revision: http://reviews.llvm.org/D7293
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227669 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-31 03:43:40 +00:00
|
|
|
void initializeTargetTransformInfoWrapperPassPass(PassRegistry &);
|
2015-01-15 10:41:28 +00:00
|
|
|
void initializeTargetLibraryInfoWrapperPassPass(PassRegistry &);
|
2015-01-04 12:03:27 +00:00
|
|
|
void initializeAssumptionCacheTrackerPass(PassRegistry &);
|
2015-02-19 19:14:34 +00:00
|
|
|
void initializeTwoAddressInstructionPassPass(PassRegistry&);
|
|
|
|
|
void initializeTypeBasedAliasAnalysisPass(PassRegistry&);
|
|
|
|
|
void initializeScopedNoAliasAAPass(PassRegistry&);
|
|
|
|
|
void initializeUnifyFunctionExitNodesPass(PassRegistry&);
|
|
|
|
|
void initializeUnreachableBlockElimPass(PassRegistry&);
|
|
|
|
|
void initializeUnreachableMachineBlockElimPass(PassRegistry&);
|
|
|
|
|
void initializeVerifierLegacyPassPass(PassRegistry&);
|
|
|
|
|
void initializeVirtRegMapPass(PassRegistry&);
|
|
|
|
|
void initializeVirtRegRewriterPass(PassRegistry&);
|
|
|
|
|
void initializeInstSimplifierPass(PassRegistry&);
|
|
|
|
|
void initializeUnpackMachineBundlesPass(PassRegistry&);
|
|
|
|
|
void initializeFinalizeMachineBundlesPass(PassRegistry&);
|
2015-02-19 19:15:04 +00:00
|
|
|
void initializeLoopAccessAnalysisPass(PassRegistry&);
|
2015-02-19 19:14:34 +00:00
|
|
|
void initializeLoopVectorizePass(PassRegistry&);
|
|
|
|
|
void initializeSLPVectorizerPass(PassRegistry&);
|
|
|
|
|
void initializeBBVectorizePass(PassRegistry&);
|
|
|
|
|
void initializeMachineFunctionPrinterPassPass(PassRegistry&);
|
|
|
|
|
void initializeStackMapLivenessPass(PassRegistry&);
|
2014-08-03 21:35:39 +00:00
|
|
|
void initializeMachineCombinerPass(PassRegistry &);
|
2014-05-29 01:55:07 +00:00
|
|
|
void initializeLoadCombinePass(PassRegistry&);
|
2014-11-07 21:32:08 +00:00
|
|
|
void initializeRewriteSymbolsPass(PassRegistry&);
|
2015-01-29 00:41:44 +00:00
|
|
|
void initializeWinEHPreparePass(PassRegistry&);
|
Add a pass for inserting safepoints into (nearly) arbitrary IR
This pass is responsible for figuring out where to place call safepoints and safepoint polls. It doesn't actually make the relocations explicit; that's the job of the RewriteStatepointsForGC pass (http://reviews.llvm.org/D6975).
Note that this code is not yet finalized. Its moving in tree for incremental development, but further cleanup is needed and will happen over the next few days. It is not yet part of the standard pass order.
Planned changes in the near future:
- I plan on restructuring the statepoint rewrite to use the functions add to the IRBuilder a while back.
- In the current pass, the function "gc.safepoint_poll" is treated specially but is not an intrinsic. I plan to make identifying the poll function a property of the GCStrategy at some point in the near future.
- As follow on patches, I will be separating a collection of test cases we have out of tree and submitting them upstream.
- It's not explicit in the code, but these two patches are introducing a new state for a statepoint which looks a lot like a patchpoint. There's no a transient form which doesn't yet have the relocations explicitly represented, but does prevent reordering of memory operations. Once this is in, I need to update actually make this explicit by reserving the 'unused' argument of the statepoint as a flag, updating the docs, and making the code explicitly check for such a thing. This wasn't really planned, but once I split the two passes - which was done for other reasons - the intermediate state fell out. Just reminds us once again that we need to merge statepoints and patchpoints at some point in the not that distant future.
Future directions planned:
- Identifying more cases where a backedge safepoint isn't required to ensure timely execution of a safepoint poll.
- Tweaking the insertion process to generate easier to optimize IR. (For example, investigating making SplitBackedge) the default.
- Adding opt-in flags for a GCStrategy to use this pass. Once done, add this pass to the actual pass ordering.
Differential Revision: http://reviews.llvm.org/D6981
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228090 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-04 00:37:33 +00:00
|
|
|
void initializePlaceBackedgeSafepointsImplPass(PassRegistry&);
|
|
|
|
|
void initializePlaceSafepointsPass(PassRegistry&);
|
2015-02-18 23:17:41 +00:00
|
|
|
void initializeDwarfEHPreparePass(PassRegistry&);
|
2010-10-07 04:17:38 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#endif
|
