6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2025-02-02 09:33:59 +00:00
Code Issues Projects Releases Wiki Activity
llvm-6502/include/llvm/InitializePasses.h

293 lines
13 KiB
C
Raw Normal View History

Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
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;
Implementation of path profiling. Modified patch by Adam Preuss. This builds on the existing framework for block tracing, edge profiling and optimal edge profiling. See -help-hidden for new flags. For documentation, see the technical report "Implementation of Path Profiling..." in llvm.org/pubs. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@124515 91177308-0d34-0410-b5e6-96231b3b80d8
2011-01-29 01:09:53 +00:00
/// initializeCore - Initialize all passes linked into the
Add initialization routines for VMCore. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115963 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 19:51:21 +00:00
/// TransformUtils library.
void initializeCore(PassRegistry&);
Implementation of path profiling. Modified patch by Adam Preuss. This builds on the existing framework for block tracing, edge profiling and optimal edge profiling. See -help-hidden for new flags. For documentation, see the technical report "Implementation of Path Profiling..." in llvm.org/pubs. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@124515 91177308-0d34-0410-b5e6-96231b3b80d8
2011-01-29 01:09:53 +00:00
/// initializeTransformUtils - Initialize all passes linked into the
Next step on the getting-rid-of-static-ctors train: begin adding per-library initialization functions that initialize the set of passes implemented in that library. Add C bindings for these functions as well. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115927 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 17:55:47 +00:00
/// TransformUtils library.
void initializeTransformUtils(PassRegistry&);
Implementation of path profiling. Modified patch by Adam Preuss. This builds on the existing framework for block tracing, edge profiling and optimal edge profiling. See -help-hidden for new flags. For documentation, see the technical report "Implementation of Path Profiling..." in llvm.org/pubs. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@124515 91177308-0d34-0410-b5e6-96231b3b80d8
2011-01-29 01:09:53 +00:00
/// initializeScalarOpts - Initialize all passes linked into the
Next step on the getting-rid-of-static-ctors train: begin adding per-library initialization functions that initialize the set of passes implemented in that library. Add C bindings for these functions as well. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115927 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 17:55:47 +00:00
/// ScalarOpts library.
void initializeScalarOpts(PassRegistry&);
Extracted ObjCARC.cpp into its own library libLLVMObjCARCOpts in preparation for refactoring the ARC Optimizer. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173647 91177308-0d34-0410-b5e6-96231b3b80d8
2013-01-28 01:35:51 +00:00
/// initializeObjCARCOpts - Initialize all passes linked into the ObjCARCOpts
/// library.
void initializeObjCARCOpts(PassRegistry&);
Add a basic-block autovectorization pass. This is the initial checkin of the basic-block autovectorization pass along with some supporting vectorization infrastructure. Special thanks to everyone who helped review this code over the last several months (especially Tobias Grosser). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149468 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-01 03:51:43 +00:00
/// initializeVectorization - Initialize all passes linked into the
/// Vectorize library.
void initializeVectorization(PassRegistry&);
Implementation of path profiling. Modified patch by Adam Preuss. This builds on the existing framework for block tracing, edge profiling and optimal edge profiling. See -help-hidden for new flags. For documentation, see the technical report "Implementation of Path Profiling..." in llvm.org/pubs. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@124515 91177308-0d34-0410-b5e6-96231b3b80d8
2011-01-29 01:09:53 +00:00
/// initializeInstCombine - Initialize all passes linked into the
[PM] Separate the InstCombiner from its pass. This creates a small internal pass which runs the InstCombiner over a function. This is the hard part of porting InstCombine to the new pass manager, as at this point none of the code in InstCombine has access to a Pass object any longer. The resulting interface for the InstCombiner is pretty terrible. I'm not planning on leaving it that way. The key thing missing is that we need to separate the worklist from the combiner a touch more. Once that's done, it should be possible for *any* part of LLVM to just create a worklist with instructions, populate it, and then combine it until empty. The pass will just be the (obvious and important) special case of doing that for an entire function body. For now, this is the first increment of factoring to make all of this work. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226618 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-20 22:44:35 +00:00
/// InstCombine library.
Add initialization routines to InstCombine. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115965 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 20:04:55 +00:00
void initializeInstCombine(PassRegistry&);
Add an initialization routine for libLLVMipo.a git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115933 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 18:09:59 +00:00
/// initializeIPO - Initialize all passes linked into the IPO library.
void initializeIPO(PassRegistry&);
Add initialization routines for Instrumentation. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115971 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 20:17:24 +00:00
/// initializeInstrumentation - Initialize all passes linked into the
/// Instrumentation library.
void initializeInstrumentation(PassRegistry&);
Add initialization routines for Analysis and IPA. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115946 91177308-0d34-0410-b5e6-96231b3b80d8
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&);
Add initialization routines for CodeGen. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115949 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 18:41:20 +00:00
/// initializeCodeGen - Initialize all passes linked into the CodeGen library.
void initializeCodeGen(PassRegistry&);
Add initialization routines for Target. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115957 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 18:50:11 +00:00
/// initializeCodeGen - Initialize all passes linked into the CodeGen library.
void initializeTarget(PassRegistry&);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
void initializeAAEvalPass(PassRegistry&);
Pass to emit DWARF path discriminators. DWARF discriminators are used to distinguish multiple control flow paths on the same source location. When this happens, instructions across basic block boundaries will share the same debug location. This pass detects this situation and creates a new lexical scope to one of the two instructions. This lexical scope is a child scope of the original and contains a new discriminator value. This discriminator is then picked up from MCObjectStreamer::EmitDwarfLocDirective to be written on the object file. This fixes http://llvm.org/bugs/show_bug.cgi?id=18270. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202752 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-03 20:06:11 +00:00
void initializeAddDiscriminatorsPass(PassRegistry&);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
void initializeADCEPass(PassRegistry&);
void initializeAliasAnalysisAnalysisGroup(PassRegistry&);
void initializeAliasAnalysisCounterPass(PassRegistry&);
void initializeAliasDebuggerPass(PassRegistry&);
void initializeAliasSetPrinterPass(PassRegistry&);
void initializeAlwaysInlinerPass(PassRegistry&);
void initializeArgPromotionPass(PassRegistry&);
Rename AtomicExpandLoadLinked into AtomicExpand AtomicExpandLoadLinked is currently rather ARM-specific. This patch is the first of a group that aim at making it more target-independent. See http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/075873.html for details The command line option is "atomic-expand" git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216231 91177308-0d34-0410-b5e6-96231b3b80d8
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&);
Add an AlignmentFromAssumptions Pass This adds a ScalarEvolution-powered transformation that updates load, store and memory intrinsic pointer alignments based on invariant((a+q) & b == 0) expressions. Many of the simple cases we can get with ValueTracking, but we still need something like this for the more complicated cases (such as those with an offset) that require some algebra. Note that gcc's __builtin_assume_aligned's optional third argument provides exactly for this kind of 'misalignment' offset for which this kind of logic is necessary. The primary motivation is to fixup alignments for vector loads/stores after vectorization (and unrolling). This pass is added to the optimization pipeline just after the SLP vectorizer runs (which, admittedly, does not preserve SE, although I imagine it could). Regardless, I actually don't think that the preservation matters too much in this case: SE computes lazily, and this pass won't issue any SE queries unless there are any assume intrinsics, so there should be no real additional cost in the common case (SLP does preserve DT and LoopInfo). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217344 91177308-0d34-0410-b5e6-96231b3b80d8
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&);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
void initializeBasicAliasAnalysisPass(PassRegistry&);
[PM] Split the CallGraph out from the ModulePass which creates the CallGraph. This makes the CallGraph a totally generic analysis object that is the container for the graph data structure and the primary interface for querying and manipulating it. The pass logic is separated into its own class. For compatibility reasons, the pass provides wrapper methods for most of the methods on CallGraph -- they all just forward. This will allow the new pass manager infrastructure to provide its own analysis pass that constructs the same CallGraph object and makes it available. The idea is that in the new pass manager, the analysis pass's 'run' method returns a concrete analysis 'result'. Here, that result is a 'CallGraph'. The 'run' method will typically do only minimal work, deferring much of the work into the implementation of the result object in order to be lazy about computing things, but when (like DomTree) there is *some* up-front computation, the analysis does it prior to handing the result back to the querying pass. I know some of this is fairly ugly. I'm happy to change it around if folks can suggest a cleaner interim state, but there is going to be some amount of unavoidable ugliness during the transition period. The good thing is that this is very limited and will naturally go away when the old pass infrastructure goes away. It won't hang around to bother us later. Next up is the initial new-PM-style call graph analysis. =] git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195722 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-26 04:19:30 +00:00
void initializeCallGraphWrapperPassPass(PassRegistry &);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
void initializeBlockExtractorPassPass(PassRegistry&);
Rename BlockFrequency to BlockFrequencyInfo and MachineBlockFrequency to MachineBlockFrequencyInfo. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135937 91177308-0d34-0410-b5e6-96231b3b80d8
2011-07-25 19:25:40 +00:00
void initializeBlockFrequencyInfoPass(PassRegistry&);
add a new pass to instrument loads and stores for run-time bounds checking move EmitGEPOffset from InstCombine to Transforms/Utils/Local.h (a draft of this) patch reviewed by Andrew, thanks. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@157261 91177308-0d34-0410-b5e6-96231b3b80d8
2012-05-22 17:19:09 +00:00
void initializeBoundsCheckingPass(PassRegistry&);
Move pass configuration out of pass constructors: BranchFolderPass git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@150095 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-08 21:22:48 +00:00
void initializeBranchFolderPassPass(PassRegistry&);
New BranchProbabilityInfo analysis. Patch by Jakub Staszak! BranchProbabilityInfo provides an interface for IR passes to query the likelihood that control follows a CFG edge. This patch provides an initial implementation of static branch predication that will populate BranchProbabilityInfo for branches with no external profile information using very simple heuristics. It currently isn't hooked up to any external profile data, so static prediction does all the work. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@132613 91177308-0d34-0410-b5e6-96231b3b80d8
2011-06-04 01:16:30 +00:00
void initializeBranchProbabilityInfoPass(PassRegistry&);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
void initializeBreakCriticalEdgesPass(PassRegistry&);
Added -view-callgraph module pass. -dot-callgraph similarly follows a standard module pass pattern. Patch by Speziale Ettore! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172220 91177308-0d34-0410-b5e6-96231b3b80d8
2013-01-11 17:28:14 +00:00
void initializeCallGraphPrinterPass(PassRegistry&);
void initializeCallGraphViewerPass(PassRegistry&);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
void initializeCFGOnlyPrinterPass(PassRegistry&);
void initializeCFGOnlyViewerPass(PassRegistry&);
void initializeCFGPrinterPass(PassRegistry&);
Factor FlattenCFG out from SimplifyCFG Patch by: Mei Ye git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187764 91177308-0d34-0410-b5e6-96231b3b80d8
2013-08-06 02:43:45 +00:00
void initializeCFGSimplifyPassPass(PassRegistry&);
Add a CFL Alias Analysis implementation This provides an implementation of CFL alias analysis (including some supporting data structures). Currently, we don't have any extremely fancy features, sans some interprocedural analysis (i.e. no field sensitivity, etc.), and we do best sitting behind BasicAA + TBAA. In such a configuration, we take ~0.6-0.8% of total compile time, and give ~7-8% NoAlias responses to queries TBAA and BasicAA couldn't answer when bootstrapping LLVM. In testing this on other projects, we've seen up to 10.5% of queries dropped by BasicAA+TBAA answered with NoAlias by this algorithm. Patch by George Burgess IV (with minor modifications by me -- mostly adapting some BasicAA tests), thanks! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216970 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-02 21:43:13 +00:00
void initializeCFLAliasAnalysisPass(PassRegistry&);
Add Forward Control-Flow Integrity. This commit adds a new pass that can inject checks before indirect calls to make sure that these calls target known locations. It supports three types of checks and, at compile time, it can take the name of a custom function to call when an indirect call check fails. The default failure function ignores the error and continues. This pass incidentally moves the function JumpInstrTables::transformType from private to public and makes it static (with a new argument that specifies the table type to use); this is so that the CFI code can transform function types at call sites to determine which jump-instruction table to use for the check at that site. Also, this removes support for jumptables in ARM, pending further performance analysis and discussion. Review: http://reviews.llvm.org/D4167 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221708 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-11 21:08:02 +00:00
void initializeForwardControlFlowIntegrityPass(PassRegistry&);
Factor FlattenCFG out from SimplifyCFG Patch by: Mei Ye git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187764 91177308-0d34-0410-b5e6-96231b3b80d8
2013-08-06 02:43:45 +00:00
void initializeFlattenCFGPassPass(PassRegistry&);
Move StructurizeCFG out of R600 to generic Transforms. Register it with PassManager git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@184343 91177308-0d34-0410-b5e6-96231b3b80d8
2013-06-19 20:18:24 +00:00
void initializeStructurizeCFGPass(PassRegistry&);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
void initializeCFGViewerPass(PassRegistry&);
Revert "Revert "Add Constant Hoisting Pass" (r200034)" This reverts commit r200058 and adds the using directive for ARMTargetTransformInfo to silence two g++ overload warnings. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200062 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-25 02:02:55 +00:00
void initializeConstantHoistingPass(PassRegistry&);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
void initializeCodeGenPreparePass(PassRegistry&);
void initializeConstantMergePass(PassRegistry&);
void initializeConstantPropagationPass(PassRegistry&);
Added a late machine instruction copy propagation pass. This catches opportunities that only present themselves after late optimizations such as tail duplication .e.g. ## BB#1: movl %eax, %ecx movl %ecx, %eax ret The register allocator also leaves some of them around (due to false dep between copies from phi-elimination, etc.) This required some changes in codegen passes. Post-ra scheduler and the pseudo-instruction expansion passes have been moved after branch folding and tail merging. They were before branch folding before because it did not always update block livein's. That's fixed now. The pass change makes independently since we want to properly schedule instructions after branch folding / tail duplication. rdar://10428165 rdar://10640363 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147716 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-07 03:02:36 +00:00
void initializeMachineCopyPropagationPass(PassRegistry&);
Add a cost model analysis that allows us to estimate the cost of IR-level instructions. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167324 91177308-0d34-0410-b5e6-96231b3b80d8
2012-11-02 21:48:17 +00:00
void initializeCostModelAnalysisPass(PassRegistry&);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
void initializeCorrelatedValuePropagationPass(PassRegistry&);
void initializeDAEPass(PassRegistry&);
void initializeDAHPass(PassRegistry&);
void initializeDCEPass(PassRegistry&);
void initializeDSEPass(PassRegistry&);
verify-di: Implement DebugInfoVerifier Implement DebugInfoVerifier, which steals verification relying on DebugInfoFinder from Verifier. - Adds LegacyDebugInfoVerifierPassPass, a ModulePass which wraps DebugInfoVerifier. Uses -verify-di command-line flag. - Change verifyModule() to invoke DebugInfoVerifier as well as Verifier. - Add a call to createDebugInfoVerifierPass() wherever there was a call to createVerifierPass(). This implementation as a module pass should sidestep efficiency issues, allowing us to turn debug info verification back on. <rdar://problem/15500563> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206300 91177308-0d34-0410-b5e6-96231b3b80d8
2014-04-15 16:27:38 +00:00
void initializeDebugInfoVerifierLegacyPassPass(PassRegistry &);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
void initializeDeadInstEliminationPass(PassRegistry&);
void initializeDeadMachineInstructionElimPass(PassRegistry&);
delinearization of arrays git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194527 91177308-0d34-0410-b5e6-96231b3b80d8
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&);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
void initializeDomOnlyPrinterPass(PassRegistry&);
void initializeDomOnlyViewerPass(PassRegistry&);
void initializeDomPrinterPass(PassRegistry&);
void initializeDomViewerPass(PassRegistry&);
void initializeDominanceFrontierPass(PassRegistry&);
[PM] Split DominatorTree into a concrete analysis result object which can be used by both the new pass manager and the old. This removes it from any of the virtual mess of the pass interfaces and lets it derive cleanly from the DominatorTreeBase<> template. In turn, tons of boilerplate interface can be nuked and it turns into a very straightforward extension of the base DominatorTree interface. The old analysis pass is now a simple wrapper. The names and style of this split should match the split between CallGraph and CallGraphWrapperPass. All of the users of DominatorTree have been updated to match using many of the same tricks as with CallGraph. The goal is that the common type remains the resulting DominatorTree rather than the pass. This will make subsequent work toward the new pass manager significantly easier. Also in numerous places things became cleaner because I switched from re-running the pass (!!! mid way through some other passes run!!!) to directly recomputing the domtree. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199104 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-13 13:07:17 +00:00
void initializeDominatorTreeWrapperPassPass(PassRegistry&);
Add an experimental early if-conversion pass, off by default. This pass performs if-conversion on SSA form machine code by speculatively executing both sides of the branch and using a cmov instruction to select the result. This can help lower the number of branch mispredictions on architectures like x86 that don't have predicable instructions. The current implementation is very aggressive, and causes regressions on mosts tests. It needs good heuristics that have yet to be implemented. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159694 91177308-0d34-0410-b5e6-96231b3b80d8
2012-07-04 00:09:54 +00:00
void initializeEarlyIfConverterPass(PassRegistry&);
Turn the EdgeBundles class into a stand-alone machine CFG analysis pass. The analysis will be needed by both the greedy register allocator and the X86FloatingPoint pass. It only needs to be computed once when the CFG doesn't change. This pass is very fast, usually showing up as 0.0% wall time. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@122832 91177308-0d34-0410-b5e6-96231b3b80d8
2011-01-04 21:10:05 +00:00
void initializeEdgeBundlesPass(PassRegistry&);
Codegen pass definition cleanup. No functionality. Moving toward a uniform style of pass definition to allow easier target configuration. Globally declare Pass ID. Globally declare pass initializer. Use INITIALIZE_PASS consistently. Add a call to the initializer from CodeGen.cpp. Remove redundant "createPass" functions and "getPassName" methods. While cleaning up declarations, cleaned up comments (sorry for large diff). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@150100 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-08 21:23:13 +00:00
void initializeExpandPostRAPass(PassRegistry&);
Rename LineProfiling to GCOVProfiling to more accurately represent what it does. Also mostly implement it. Still a work-in-progress, but generates legal output on crafted test cases. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@129630 91177308-0d34-0410-b5e6-96231b3b80d8
2011-04-16 01:20:23 +00:00
void initializeGCOVProfilerPass(PassRegistry&);
InstrProf: An intrinsic and lowering for instrumentation based profiling Introduce the ``llvm.instrprof_increment`` intrinsic and the ``-instrprof`` pass. These provide the infrastructure for writing counters for profiling, as in clang's ``-fprofile-instr-generate``. The implementation of the instrprof pass is ported directly out of the CodeGenPGO classes in clang, and with the followup in clang that rips that code out to use these new intrinsics this ends up being NFC. Doing the instrumentation this way opens some doors in terms of improving the counter performance. For example, this will make it simple to experiment with alternate lowering strategies, and allows us to try handling profiling specially in some optimizations if we want to. Finally, this drastically simplifies the frontend and puts all of the lowering logic in one place. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223672 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-08 18:02:35 +00:00
void initializeInstrProfilingPass(PassRegistry&);
AddressSanitizer, first commit (compiler module only) git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@144758 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-16 01:35:23 +00:00
void initializeAddressSanitizerPass(PassRegistry&);
[asan] Split AddressSanitizer into two passes (FunctionPass, ModulePass), LLVM part. This requires a clang part which will follow. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168781 91177308-0d34-0410-b5e6-96231b3b80d8
2012-11-28 10:31:36 +00:00
void initializeAddressSanitizerModulePass(PassRegistry&);
Initial commit of MemorySanitizer. Compiler pass only. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168866 91177308-0d34-0410-b5e6-96231b3b80d8
2012-11-29 09:57:20 +00:00
void initializeMemorySanitizerPass(PassRegistry&);
ThreadSanitizer, a race detector. First LLVM commit. Clang patch (flags) will follow shortly. The run-time library will also follow, but not immediately. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@150423 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-13 22:50:51 +00:00
void initializeThreadSanitizerPass(PassRegistry&);
Move asan-coverage into a separate phase. Summary: This change moves asan-coverage instrumentation into a separate Module pass. The other part of the change in clang introduces a new flag -fsanitize-coverage=N. Another small patch will update tests in compiler-rt. With this patch no functionality change is expected except for the flag name. The following changes will make the coverage instrumentation work with tsan/msan Test Plan: Run regression tests, chromium. Reviewers: nlewycky, samsonov Reviewed By: nlewycky, samsonov Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D6152 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221718 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-11 22:14:37 +00:00
void initializeSanitizerCoverageModulePass(PassRegistry&);
DataFlowSanitizer; LLVM changes. DataFlowSanitizer is a generalised dynamic data flow analysis. Unlike other Sanitizer tools, this tool is not designed to detect a specific class of bugs on its own. Instead, it provides a generic dynamic data flow analysis framework to be used by clients to help detect application-specific issues within their own code. Differential Revision: http://llvm-reviews.chandlerc.com/D965 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187923 91177308-0d34-0410-b5e6-96231b3b80d8
2013-08-07 22:47:18 +00:00
void initializeDataFlowSanitizerPass(PassRegistry&);
Add a Scalarizer pass. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195471 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-22 16:58:05 +00:00
void initializeScalarizerPass(PassRegistry&);
[PM] Refactor the core logic to run EarlyCSE over a function into an object that manages a single run of this pass. This was already essentially how it worked. Within the run function, it would point members at *stack local* allocations that were only live for a single run. Instead, it seems much cleaner to have a utility object whose lifetime is clearly bounded by the run of the pass over the function and can use member variables in a more direct way. This also makes it easy to plumb the analyses used into it from the pass and will make it re-usable with the new pass manager. No functionality changed here, its just a refactoring. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227162 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-27 01:34:14 +00:00
void initializeEarlyCSELegacyPassPass(PassRegistry &);
Rename ExpandPseudos to ExpandISelPseudos to help clarify its role. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@119716 91177308-0d34-0410-b5e6-96231b3b80d8
2010-11-18 18:45:06 +00:00
void initializeExpandISelPseudosPass(PassRegistry&);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
void initializeFunctionAttrsPass(PassRegistry&);
Codegen pass definition cleanup. No functionality. Moving toward a uniform style of pass definition to allow easier target configuration. Globally declare Pass ID. Globally declare pass initializer. Use INITIALIZE_PASS consistently. Add a call to the initializer from CodeGen.cpp. Remove redundant "createPass" functions and "getPassName" methods. While cleaning up declarations, cleaned up comments (sorry for large diff). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@150100 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-08 21:23:13 +00:00
void initializeGCMachineCodeAnalysisPass(PassRegistry&);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
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&);
Add a new pass "inductive range check elimination" IRCE eliminates range checks of the form 0 <= A * I + B < Length by splitting a loop's iteration space into three segments in a way that the check is completely redundant in the middle segment. As an example, IRCE will convert len = < known positive > for (i = 0; i < n; i++) { if (0 <= i && i < len) { do_something(); } else { throw_out_of_bounds(); } } to len = < known positive > limit = smin(n, len) // no first segment for (i = 0; i < limit; i++) { if (0 <= i && i < len) { // this check is fully redundant do_something(); } else { throw_out_of_bounds(); } } for (i = limit; i < n; i++) { if (0 <= i && i < len) { do_something(); } else { throw_out_of_bounds(); } } IRCE can deal with multiple range checks in the same loop (it takes the intersection of the ranges that will make each of them redundant individually). Currently IRCE does not do any profitability analysis. That is a TODO. Please note that the status of this pass is *experimental*, and it is not part of any default pass pipeline. Having said that, I will love to get feedback and general input from people interested in trying this out. This pass was originally r226201. It was reverted because it used C++ features not supported by MSVC 2012. Differential Revision: http://reviews.llvm.org/D6693 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226238 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-16 01:03:22 +00:00
void initializeInductiveRangeCheckEliminationPass(PassRegistry&);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
void initializeIndVarSimplifyPass(PassRegistry&);
Make the inline cost a proper analysis pass. This remains essentially a dynamic analysis done on each call to the routine. However, now it can use the standard pass infrastructure to reference other analyses, instead of a silly setter method. This will become more interesting as I teach it about more analysis passes. This updates the two inliner passes to use the inline cost analysis. Doing so highlights how utterly redundant these two passes are. Either we should find a cheaper way to do always inlining, or we should merge the two and just fiddle with the thresholds to get the desired behavior. I'm leaning increasingly toward the latter as it would also remove the Inliner sub-class split. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@173030 91177308-0d34-0410-b5e6-96231b3b80d8
2013-01-21 11:39:18 +00:00
void initializeInlineCostAnalysisPass(PassRegistry&);
[PM] Separate the InstCombiner from its pass. This creates a small internal pass which runs the InstCombiner over a function. This is the hard part of porting InstCombine to the new pass manager, as at this point none of the code in InstCombine has access to a Pass object any longer. The resulting interface for the InstCombiner is pretty terrible. I'm not planning on leaving it that way. The key thing missing is that we need to separate the worklist from the combiner a touch more. Once that's done, it should be possible for *any* part of LLVM to just create a worklist with instructions, populate it, and then combine it until empty. The pass will just be the (obvious and important) special case of doing that for an entire function body. For now, this is the first increment of factoring to make all of this work. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226618 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-20 22:44:35 +00:00
void initializeInstructionCombiningPassPass(PassRegistry&);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
void initializeInstCountPass(PassRegistry&);
void initializeInstNamerPass(PassRegistry&);
void initializeInternalizePassPass(PassRegistry&);
void initializeIntervalPartitionPass(PassRegistry&);
Add a new attribute called 'jumptable' that creates jump-instruction tables for functions marked with this attribute. It includes a pass that rewrites all indirect calls to jumptable functions to pass through these tables. This also adds backend support for generating the jump-instruction tables on ARM and X86. Note that since the jumptable attribute creates a second function pointer for a function, any function marked with jumptable must also be marked with unnamed_addr. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210280 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-05 19:29:43 +00:00
void initializeJumpInstrTableInfoPass(PassRegistry&);
void initializeJumpInstrTablesPass(PassRegistry&);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
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&);
Stub out a new LiveDebugVariables pass. This analysis is going to run immediately after LiveIntervals. It will stay alive during register allocation and keep track of user variables mentioned in DBG_VALUE instructions. When the register allocator is moving values between registers and the stack, it is very hard to keep track of DBG_VALUE instructions. We usually get it wrong. This analysis maintains a data structure that makes it easy to update DBG_VALUE instructions. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120385 91177308-0d34-0410-b5e6-96231b3b80d8
2010-11-30 02:17:10 +00:00
void initializeLiveDebugVariablesPass(PassRegistry&);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
void initializeLiveIntervalsPass(PassRegistry&);
Sketch a LiveRegMatrix analysis pass. The LiveRegMatrix represents the live range of assigned virtual registers in a Live interval union per register unit. This is not fundamentally different from the interference tracking in RegAllocBase that both RABasic and RAGreedy use. The important differences are: - LiveRegMatrix tracks interference per register unit instead of per physical register. This makes interference checks cheaper and assignments slightly more expensive. For example, the ARM D7 reigster has 24 aliases, so we would check 24 physregs before assigning to one. With unit-based interference, we check 2 units before assigning to 2 units. - LiveRegMatrix caches regmask interference checks. That is currently duplicated functionality in RABasic and RAGreedy. - LiveRegMatrix is a pass which makes it possible to insert target-dependent passes between register allocation and rewriting. Such passes could tweak the register assignments with interference checking support from LiveRegMatrix. Eventually, RABasic and RAGreedy will be switched to LiveRegMatrix. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158255 91177308-0d34-0410-b5e6-96231b3b80d8
2012-06-09 02:13:10 +00:00
void initializeLiveRegMatrixPass(PassRegistry&);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
void initializeLiveStacksPass(PassRegistry&);
void initializeLiveVariablesPass(PassRegistry&);
void initializeLoaderPassPass(PassRegistry&);
Codegen pass definition cleanup. No functionality. Moving toward a uniform style of pass definition to allow easier target configuration. Globally declare Pass ID. Globally declare pass initializer. Use INITIALIZE_PASS consistently. Add a call to the initializer from CodeGen.cpp. Remove redundant "createPass" functions and "getPassName" methods. While cleaning up declarations, cleaned up comments (sorry for large diff). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@150100 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-08 21:23:13 +00:00
void initializeLocalStackSlotPassPass(PassRegistry&);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
void initializeLoopDeletionPass(PassRegistry&);
void initializeLoopExtractorPass(PassRegistry&);
[PM] Split the LoopInfo object apart from the legacy pass, creating a LoopInfoWrapperPass to wire the object up to the legacy pass manager. This switches all the clients of LoopInfo over and paves the way to port LoopInfo to the new pass manager. No functionality change is intended with this iteration. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226373 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-17 14:16:18 +00:00
void initializeLoopInfoWrapperPassPass(PassRegistry&);
Add a new loop-instsimplify pass, with the intention of replacing the instance of instcombine that is currently in the middle of the loop pass pipeline. This commit only checks in the pass; it will hopefully be enabled by default later. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@122719 91177308-0d34-0410-b5e6-96231b3b80d8
2011-01-03 00:25:16 +00:00
void initializeLoopInstSimplifyPass(PassRegistry&);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
void initializeLoopRotatePass(PassRegistry&);
void initializeLoopSimplifyPass(PassRegistry&);
void initializeLoopStrengthReducePass(PassRegistry&);
svn mv Target/ARM/ARMGlobalMerge.cpp Transforms/Scalar/GlobalMerge.cpp There is no reason to have simple IR level pass in lib/Target. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142200 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-17 17:17:43 +00:00
void initializeGlobalMergePass(PassRegistry&);
Add a loop rerolling pass This adds a loop rerolling pass: the opposite of (partial) loop unrolling. The transformation aims to take loops like this: for (int i = 0; i < 3200; i += 5) { a[i] += alpha * b[i]; a[i + 1] += alpha * b[i + 1]; a[i + 2] += alpha * b[i + 2]; a[i + 3] += alpha * b[i + 3]; a[i + 4] += alpha * b[i + 4]; } and turn them into this: for (int i = 0; i < 3200; ++i) { a[i] += alpha * b[i]; } and loops like this: for (int i = 0; i < 500; ++i) { x[3*i] = foo(0); x[3*i+1] = foo(0); x[3*i+2] = foo(0); } and turn them into this: for (int i = 0; i < 1500; ++i) { x[i] = foo(0); } There are two motivations for this transformation: 1. Code-size reduction (especially relevant, obviously, when compiling for code size). 2. Providing greater choice to the loop vectorizer (and generic unroller) to choose the unrolling factor (and a better ability to vectorize). The loop vectorizer can take vector lengths and register pressure into account when choosing an unrolling factor, for example, and a pre-unrolled loop limits that choice. This is especially problematic if the manual unrolling was optimized for a machine different from the current target. The current implementation is limited to single basic-block loops only. The rerolling recognition should work regardless of how the loop iterations are intermixed within the loop body (subject to dependency and side-effect constraints), but the significant restriction is that the order of the instructions in each iteration must be identical. This seems sufficient to capture all current use cases. This pass is not currently enabled by default at any optimization level. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@194939 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-16 23:59:05 +00:00
void initializeLoopRerollPass(PassRegistry&);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
void initializeLoopUnrollPass(PassRegistry&);
void initializeLoopUnswitchPass(PassRegistry&);
Start of a pass for recognizing memset and memcpy idioms. No functionality yet. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@122562 91177308-0d34-0410-b5e6-96231b3b80d8
2010-12-26 19:32:44 +00:00
void initializeLoopIdiomRecognizePass(PassRegistry&);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
void initializeLowerAtomicPass(PassRegistry&);
Introduce "expect" intrinsic instructions. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134516 91177308-0d34-0410-b5e6-96231b3b80d8
2011-07-06 18:22:43 +00:00
void initializeLowerExpectIntrinsicPass(PassRegistry&);
Get rid of static constructors for pass registration. Instead, every pass exposes an initializeMyPassFunction(), which must be called in the pass's constructor. This function uses static dependency declarations to recursively initialize the pass's dependencies. Clients that only create passes through the createFooPass() APIs will require no changes. Clients that want to use the CommandLine options for passes will need to manually call the appropriate initialization functions in PassInitialization.h before parsing commandline arguments. I have tested this with all standard configurations of clang and llvm-gcc on Darwin. It is possible that there are problems with the static dependencies that will only be visible with non-standard options. If you encounter any crash in pass registration/creation, please send the testcase to me directly. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@116820 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-19 17:21:58 +00:00
void initializeLowerIntrinsicsPass(PassRegistry&);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
void initializeLowerInvokePass(PassRegistry&);
void initializeLowerSwitchPass(PassRegistry&);
Rename BlockFrequency to BlockFrequencyInfo and MachineBlockFrequency to MachineBlockFrequencyInfo. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@135937 91177308-0d34-0410-b5e6-96231b3b80d8
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&);
Begin collecting some of the statistics for block placement discussed on the mailing list. Suggestions for other statistics to collect would be awesome. =] Currently these are implemented as a separate pass guarded by a separate flag. I'm not thrilled by that, but I wanted to be able to collect the statistics for the old code placement as well as the new in order to have a point of comparison. I'm planning on folding them into the single pass if / when there is only one pass of interest. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@143537 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-02 07:17:12 +00:00
void initializeMachineBlockPlacementStatsPass(PassRegistry&);
Introduce MachineBranchProbabilityInfo class, which has similar API to BranchProbabilityInfo (expect setEdgeWeight which is not available here). Branch Weights are kept in MachineBasicBlocks. To turn off this analysis set -use-mbpi=false. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133184 91177308-0d34-0410-b5e6-96231b3b80d8
2011-06-16 20:22:37 +00:00
void initializeMachineBranchProbabilityInfoPass(PassRegistry&);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
void initializeMachineCSEPass(PassRegistry&);
void initializeMachineDominatorTreePass(PassRegistry&);
Templatify DominanceFrontier. Theoretically this should now work for MachineBasicBlocks. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212885 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-12 21:59:52 +00:00
void initializeMachineDominanceFrontierPass(PassRegistry&);
Add a MachinePostDominator pass This is used in the AMDIL and R600 backends. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164029 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-17 14:08:37 +00:00
void initializeMachinePostDominatorTreePass(PassRegistry&);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
void initializeMachineLICMPass(PassRegistry&);
void initializeMachineLoopInfoPass(PassRegistry&);
void initializeMachineModuleInfoPass(PassRegistry&);
Templatify RegionInfo so it works on MachineBasicBlocks git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213456 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-19 18:29:29 +00:00
void initializeMachineRegionInfoPassPass(PassRegistry&);
Renamed MachineScheduler to ScheduleTopDownLive. Responding to code review. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148290 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-17 06:55:03 +00:00
void initializeMachineSchedulerPass(PassRegistry&);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
void initializeMachineSinkingPass(PassRegistry&);
Start scaffolding for a MachineTraceMetrics analysis pass. This is still a work in progress. Out-of-order CPUs usually execute instructions from multiple basic blocks simultaneously, so it is necessary to look at longer traces when estimating the performance effects of code transformations. The MachineTraceMetrics analysis will pick a typical trace through a given basic block and provide performance metrics for the trace. Metrics will include: - Instruction count through the trace. - Issue count per functional unit. - Critical path length, and per-instruction 'slack'. These metrics can be used to determine the performance limiting factor when executing the trace, and how it will be affected by a code transformation. Initially, this will be used by the early if-conversion pass. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@160796 91177308-0d34-0410-b5e6-96231b3b80d8
2012-07-26 18:38:11 +00:00
void initializeMachineTraceMetricsPass(PassRegistry&);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
void initializeMachineVerifierPassPass(PassRegistry&);
void initializeMemCpyOptPass(PassRegistry&);
void initializeMemDepPrinterPass(PassRegistry&);
void initializeMemoryDependenceAnalysisPass(PassRegistry&);
MergedLoadStoreMotion pass Merges equivalent loads on both sides of a hammock/diamond and hoists into into the header. Merges equivalent stores on both sides of a hammock/diamond and sinks it to the footer. Can enable if conversion and tolerate better load misses and store operand latencies. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213396 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-18 19:13:09 +00:00
void initializeMergedLoadStoreMotionPass(PassRegistry &);
Add a pass that renames everything with metasyntatic names. This works well after using bugpoint to reduce the confusion presented by the original names, which no longer mean what they used to. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163592 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-11 02:46:18 +00:00
void initializeMetaRenamerPass(PassRegistry&);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
void initializeMergeFunctionsPass(PassRegistry&);
void initializeModuleDebugInfoPrinterPass(PassRegistry&);
void initializeNoAAPass(PassRegistry&);
The ARC language-specific optimizer. Credit to Dan Gohman. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133108 91177308-0d34-0410-b5e6-96231b3b80d8
2011-06-15 23:37:01 +00:00
void initializeObjCARCAliasAnalysisPass(PassRegistry&);
Add a new ObjC ARC optimization pass to eliminate unneeded autorelease push+pop pairs. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148330 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-17 20:52:24 +00:00
void initializeObjCARCAPElimPass(PassRegistry&);
The ARC language-specific optimizer. Credit to Dan Gohman. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133108 91177308-0d34-0410-b5e6-96231b3b80d8
2011-06-15 23:37:01 +00:00
void initializeObjCARCExpandPass(PassRegistry&);
void initializeObjCARCContractPass(PassRegistry&);
void initializeObjCARCOptPass(PassRegistry&);
Add back r222061 with a fix. This adds back r222061, but now calls initializePAEvalPass from the correct library to avoid link problems. Original message: Don't make assumptions about the name of private global variables. Private variables are can be renamed, so it is not reliable to make decisions on the name. The name is also dropped by the assembler before getting to the linker, so using the name causes a disconnect between how llvm makes a decision (var name) and how the linker makes a decision (section it is in). This patch changes one case where we were looking at the variable name to use the section instead. Test tuning by Michael Gottesman. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222117 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-17 02:28:27 +00:00
void initializePAEvalPass(PassRegistry &);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
void initializeOptimizePHIsPass(PassRegistry&);
Turn MipsOptimizeMathLibCalls into a target-independent scalar transform ...so that it can be used for z too. Most of the code is the same. The only real change is to use TargetTransformInfo to test when a sqrt instruction is available. The pass is opt-in because at the moment it only handles sqrt. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189097 91177308-0d34-0410-b5e6-96231b3b80d8
2013-08-23 10:27:02 +00:00
void initializePartiallyInlineLibCallsPass(PassRegistry&);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
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&);
Codegen pass definition cleanup. No functionality. Moving toward a uniform style of pass definition to allow easier target configuration. Globally declare Pass ID. Globally declare pass initializer. Use INITIALIZE_PASS consistently. Add a call to the initializer from CodeGen.cpp. Remove redundant "createPass" functions and "getPassName" methods. While cleaning up declarations, cleaned up comments (sorry for large diff). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@150100 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-08 21:23:13 +00:00
void initializePostRASchedulerPass(PassRegistry&);
Stub out a PostMachineScheduler pass. Placeholder and boilerplate for a PostRA MachineScheduler pass. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198120 91177308-0d34-0410-b5e6-96231b3b80d8
2013-12-28 21:56:51 +00:00
void initializePostMachineSchedulerPass(PassRegistry&);
[PM] Add module and function printing passes for the new pass manager. This implements the legacy passes in terms of the new ones. It adds basic testing using explicit runs of the passes. Next up will be wiring the basic output mechanism of opt up when the new pass manager is engaged unless bitcode writing is requested. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199049 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-12 12:15:39 +00:00
void initializePrintFunctionPassWrapperPass(PassRegistry&);
void initializePrintModulePassWrapperPass(PassRegistry&);
Enable *BasicBlockPass::createPrinterPass() Enables raw_ostream I/O for BasicBlockPass. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@174776 91177308-0d34-0410-b5e6-96231b3b80d8
2013-02-08 23:37:41 +00:00
void initializePrintBasicBlockPassPass(PassRegistry&);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
void initializeProcessImplicitDefsPass(PassRegistry&);
void initializePromotePassPass(PassRegistry&);
void initializePruneEHPass(PassRegistry&);
void initializeReassociatePass(PassRegistry&);
void initializeRegToMemPass(PassRegistry&);
Templatify RegionInfo so it works on MachineBasicBlocks git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213456 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-19 18:29:29 +00:00
void initializeRegionInfoPassPass(PassRegistry&);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
void initializeRegionOnlyPrinterPass(PassRegistry&);
void initializeRegionOnlyViewerPass(PassRegistry&);
void initializeRegionPrinterPass(PassRegistry&);
void initializeRegionViewerPass(PassRegistry&);
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&);
Remove outdated references to dominance frontiers. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@123724 91177308-0d34-0410-b5e6-96231b3b80d8
2011-01-18 03:53:26 +00:00
void initializeSROA_DTPass(PassRegistry&);
split SROA into two passes: one that uses DomFrontiers (-scalarrepl) and one that uses SSAUpdater (-scalarrepl-ssa) git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@123436 91177308-0d34-0410-b5e6-96231b3b80d8
2011-01-14 08:13:00 +00:00
void initializeSROA_SSAUpPass(PassRegistry&);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
void initializeScalarEvolutionAliasAnalysisPass(PassRegistry&);
void initializeScalarEvolutionPass(PassRegistry&);
void initializeSimpleInlinerPass(PassRegistry&);
Remove gc.root's performCustomLowering This is a refactoring to restructure the single user of performCustomLowering as a specific lowering pass and remove the custom lowering hook entirely. Before this change, the LowerIntrinsics pass (note to self: rename!) was essentially acting as a pass manager, but without being structured in terms of passes. Instead, it proxied calls to a set of GCStrategies internally. This adds a lot of conceptual complexity (i.e. GCStrategies are stateful!) for very little benefit. Since there's been interest in keeping the ShadowStackGC working, I extracting it's custom lowering pass into a dedicated pass and just added that to the pass order. It will only run for functions which opt-in to that gc. I wasn't able to find an easy way to preserve the runtime registration of custom lowering functionality. Given that no user of this exists that I'm aware of, I made the choice to just remove that. If someone really cares, we can look at restoring it via dynamic pass registration in the future. Note that despite the large diff, none of the lowering code actual changes. I added the framing needed to make it a pass and rename the class, but that's it. Differential Revision: http://reviews.llvm.org/D7218 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227351 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-28 19:28:03 +00:00
void initializeShadowStackGCLoweringPass(PassRegistry&);
There is only one register coalescer. Merge it into the base class and remove the analysis group. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@133899 91177308-0d34-0410-b5e6-96231b3b80d8
2011-06-26 22:34:10 +00:00
void initializeRegisterCoalescerPass(PassRegistry&);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
void initializeSingleLoopExtractorPass(PassRegistry&);
void initializeSinkingPass(PassRegistry&);
Add an optimization that does CSE in a group of similar GEPs. This optimization merges the common part of a group of GEPs, so we can compute each pointer address by adding a simple offset to the common part. The optimization is currently only enabled for the NVPTX backend, where it has a large payoff on some benchmarks. Review: http://reviews.llvm.org/D3462 Patch by Jingyue Wu. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207783 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-01 18:38:36 +00:00
void initializeSeparateConstOffsetFromGEPPass(PassRegistry &);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
void initializeSlotIndexesPass(PassRegistry&);
Add the SpillPlacement analysis pass. This pass precomputes CFG block frequency information that can be used by the register allocator to find optimal spill code placement. Given an interference pattern, placeSpills() will compute which basic blocks should have the current variable enter or exit in a register, and which blocks prefer the stack. The algorithm is ready to consume block frequencies from profiling data, but for now it gets by with the static estimates used for spill weights. This is a work in progress and still not hooked up to RegAllocGreedy. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@122938 91177308-0d34-0410-b5e6-96231b3b80d8
2011-01-06 01:21:53 +00:00
void initializeSpillPlacementPass(PassRegistry&);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
void initializeStackProtectorPass(PassRegistry&);
Add a new optimization pass: Stack Coloring, that merges disjoint static allocations (allocas). Allocas are known to be disjoint if they are marked by disjoint lifetime markers (@llvm.lifetime.XXX intrinsics). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163299 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-06 09:17:37 +00:00
void initializeStackColoringPass(PassRegistry&);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
void initializeStackSlotColoringPass(PassRegistry&);
void initializeStripDeadDebugInfoPass(PassRegistry&);
void initializeStripDeadPrototypesPassPass(PassRegistry&);
void initializeStripDebugDeclarePass(PassRegistry&);
void initializeStripNonDebugSymbolsPass(PassRegistry&);
void initializeStripSymbolsPass(PassRegistry&);
void initializeTailCallElimPass(PassRegistry&);
Codegen pass definition cleanup. No functionality. Moving toward a uniform style of pass definition to allow easier target configuration. Globally declare Pass ID. Globally declare pass initializer. Use INITIALIZE_PASS consistently. Add a call to the initializer from CodeGen.cpp. Remove redundant "createPass" functions and "getPassName" methods. While cleaning up declarations, cleaned up comments (sorry for large diff). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@150100 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-08 21:23:13 +00:00
void initializeTailDuplicatePassPass(PassRegistry&);
Make TargetPassConfig an ImmutablePass so CodeGenPasses can query options git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149752 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-04 02:56:45 +00:00
void initializeTargetPassConfigPass(PassRegistry&);
Make DataLayout a plain object, not a pass. Instead, have a DataLayoutPass that holds one. This will allow parts of LLVM don't don't handle passes to also use DataLayout. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202168 91177308-0d34-0410-b5e6-96231b3b80d8
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 &);
[PM] Separate the TargetLibraryInfo object from the immutable pass. The pass is really just a means of accessing a cached instance of the TargetLibraryInfo object, and this way we can re-use that object for the new pass manager as its result. Lots of delta, but nothing interesting happening here. This is the common pattern that is developing to allow analyses to live in both the old and new pass manager -- a wrapper pass in the old pass manager emulates the separation intrinsic to the new pass manager between the result and pass for analyses. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@226157 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-15 10:41:28 +00:00
void initializeTargetLibraryInfoWrapperPassPass(PassRegistry &);
[PM] Split the AssumptionTracker immutable pass into two separate APIs: a cache of assumptions for a single function, and an immutable pass that manages those caches. The motivation for this change is two fold. Immutable analyses are really hacks around the current pass manager design and don't exist in the new design. This is usually OK, but it requires that the core logic of an immutable pass be reasonably partitioned off from the pass logic. This change does precisely that. As a consequence it also paves the way for the *many* utility functions that deal in the assumptions to live in both pass manager worlds by creating an separate non-pass object with its own independent API that they all rely on. Now, the only bits of the system that deal with the actual pass mechanics are those that actually need to deal with the pass mechanics. Once this separation is made, several simplifications become pretty obvious in the assumption cache itself. Rather than using a set and callback value handles, it can just be a vector of weak value handles. The callers can easily skip the handles that are null, and eventually we can wrap all of this up behind a filter iterator. For now, this adds boiler plate to the various passes, but this kind of boiler plate will end up making it possible to port these passes to the new pass manager, and so it will end up factored away pretty reasonably. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@225131 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-04 12:03:27 +00:00
void initializeAssumptionCacheTrackerPass(PassRegistry &);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
void initializeTwoAddressInstructionPassPass(PassRegistry&);
void initializeTypeBasedAliasAnalysisPass(PassRegistry&);
Add scoped-noalias metadata This commit adds scoped noalias metadata. The primary motivations for this feature are: 1. To preserve noalias function attribute information when inlining 2. To provide the ability to model block-scope C99 restrict pointers Neither of these two abilities are added here, only the necessary infrastructure. In fact, there should be no change to existing functionality, only the addition of new features. The logic that converts noalias function parameters into this metadata during inlining will come in a follow-up commit. What is added here is the ability to generally specify noalias memory-access sets. Regarding the metadata, alias-analysis scopes are defined similar to TBAA nodes: !scope0 = metadata !{ metadata !"scope of foo()" } !scope1 = metadata !{ metadata !"scope 1", metadata !scope0 } !scope2 = metadata !{ metadata !"scope 2", metadata !scope0 } !scope3 = metadata !{ metadata !"scope 2.1", metadata !scope2 } !scope4 = metadata !{ metadata !"scope 2.2", metadata !scope2 } Loads and stores can be tagged with an alias-analysis scope, and also, with a noalias tag for a specific scope: ... = load %ptr1, !alias.scope !{ !scope1 } ... = load %ptr2, !alias.scope !{ !scope1, !scope2 }, !noalias !{ !scope1 } When evaluating an aliasing query, if one of the instructions is associated with an alias.scope id that is identical to the noalias scope associated with the other instruction, or is a descendant (in the scope hierarchy) of the noalias scope associated with the other instruction, then the two memory accesses are assumed not to alias. Note that is the first element of the scope metadata is a string, then it can be combined accross functions and translation units. The string can be replaced by a self-reference to create globally unqiue scope identifiers. [Note: This overview is slightly stylized, since the metadata nodes really need to just be numbers (!0 instead of !scope0), and the scope lists are also global unnamed metadata.] Existing noalias metadata in a callee is "cloned" for use by the inlined code. This is necessary because the aliasing scopes are unique to each call site (because of possible control dependencies on the aliasing properties). For example, consider a function: foo(noalias a, noalias b) { *a = *b; } that gets inlined into bar() { ... if (...) foo(a1, b1); ... if (...) foo(a2, b2); } -- now just because we know that a1 does not alias with b1 at the first call site, and a2 does not alias with b2 at the second call site, we cannot let inlining these functons have the metadata imply that a1 does not alias with b2. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213864 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-24 14:25:39 +00:00
void initializeScopedNoAliasAAPass(PassRegistry&);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
void initializeUnifyFunctionExitNodesPass(PassRegistry&);
void initializeUnreachableBlockElimPass(PassRegistry&);
void initializeUnreachableMachineBlockElimPass(PassRegistry&);
[PM] Wire up the Verifier for the new pass manager and connect it to the various opt verifier commandline options. Mostly mechanical wiring of the verifier to the new pass manager. Exercises one of the more unusual aspects of it -- a pass can be either a module or function pass interchangably. If this is ever problematic, we can make things more constrained, but for things like the verifier where there is an "obvious" applicability at both levels, it seems convenient. This is the next-to-last piece of basic functionality left to make the opt commandline driving of the new pass manager minimally functional for testing and further development. There is still a lot to be done there (notably the factoring into .def files to kill the current boilerplate code) but it is relatively uninteresting. The only interesting bit left for minimal functionality is supporting the registration of analyses. I'm planning on doing that on top of the .def file switch mostly because the boilerplate for the analyses would be significantly worse. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199646 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-20 11:34:08 +00:00
void initializeVerifierLegacyPassPass(PassRegistry&);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
void initializeVirtRegMapPass(PassRegistry&);
Reintroduce VirtRegRewriter. OK, not really. We don't want to reintroduce the old rewriter hacks. This patch extracts virtual register rewriting as a separate pass that runs after the register allocator. This is possible now that CodeGen/Passes.cpp can configure the full optimizing register allocator pipeline. The rewriter pass uses register assignments in VirtRegMap to rewrite virtual registers to physical registers, and it inserts kill flags based on live intervals. These finalization steps are the same for the optimizing register allocators: RABasic, RAGreedy, and PBQP. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@158244 91177308-0d34-0410-b5e6-96231b3b80d8
2012-06-08 23:44:45 +00:00
void initializeVirtRegRewriterPass(PassRegistry&);
Add a new convenience pass for testing InstructionSimplify. Previously it could only be tested indirectly, via instcombine, gvn or some other pass that makes use of InstructionSimplify, which means that testcases had to be carefully contrived to dance around any other transformations that that pass did. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@122264 91177308-0d34-0410-b5e6-96231b3b80d8
2010-12-20 20:54:37 +00:00
void initializeInstSimplifierPass(PassRegistry&);
- Add MachineInstrBundle.h and MachineInstrBundle.cpp. This includes a function to finalize MI bundles (i.e. add BUNDLE instruction and computing register def and use lists of the BUNDLE instruction) and a pass to unpack bundles. - Teach more of MachineBasic and MachineInstr methods to be bundle aware. - Switch Thumb2 IT block to MI bundles and delete the hazard recognizer hack to prevent IT blocks from being broken apart. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@146542 91177308-0d34-0410-b5e6-96231b3b80d8
2011-12-14 02:11:42 +00:00
void initializeUnpackMachineBundlesPass(PassRegistry&);
More bundle related API additions. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148465 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-19 07:47:03 +00:00
void initializeFinalizeMachineBundlesPass(PassRegistry&);
Add a loop vectorizer. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@166112 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-17 18:25:06 +00:00
void initializeLoopVectorizePass(PassRegistry&);
Add support for bottom-up SLP vectorization infrastructure. This commit adds the infrastructure for performing bottom-up SLP vectorization (and other optimizations) on parallel computations. The infrastructure has three potential users: 1. The loop vectorizer needs to be able to vectorize AOS data structures such as (sum += A[i] + A[i+1]). 2. The BB-vectorizer needs this infrastructure for bottom-up SLP vectorization, because bottom-up vectorization is faster to compute. 3. A loop-roller needs to be able to analyze consecutive chains and roll them into a loop, in order to reduce code size. A loop roller does not need to create vector instructions, and this infrastructure separates the chain analysis from the vectorization. This patch also includes a simple (100 LOC) bottom up SLP vectorizer that uses the infrastructure, and can vectorize this code: void SAXPY(int *x, int *y, int a, int i) { x[i] = a * x[i] + y[i]; x[i+1] = a * x[i+1] + y[i+1]; x[i+2] = a * x[i+2] + y[i+2]; x[i+3] = a * x[i+3] + y[i+3]; } git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179117 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-09 19:44:35 +00:00
void initializeSLPVectorizerPass(PassRegistry&);
Add a basic-block autovectorization pass. This is the initial checkin of the basic-block autovectorization pass along with some supporting vectorization infrastructure. Special thanks to everyone who helped review this code over the last several months (especially Tobias Grosser). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149468 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-01 03:51:43 +00:00
void initializeBBVectorizePass(PassRegistry&);
Add an insertPass API to TargetPassConfig. <rdar://problem/11498613> Besides adding the new insertPass function, this patch uses it to enhance the existing -print-machineinstrs so that the MachineInstrs after a specific pass can be printed. Patch by Bin Zeng! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@157655 91177308-0d34-0410-b5e6-96231b3b80d8
2012-05-30 00:17:12 +00:00
void initializeMachineFunctionPrinterPassPass(PassRegistry&);
[Stackmap] Liveness Analysis Pass This optional register liveness analysis pass can be enabled with either -enable-stackmap-liveness, -enable-patchpoint-liveness, or both. The pass traverses each basic block in a machine function. For each basic block the instructions are processed in reversed order and if a patchpoint or stackmap instruction is encountered the current live-out register set is encoded as a register mask and attached to the instruction. Later on during stackmap generation the live-out register mask is processed and also emitted as part of the stackmap. This information is optional and intended for optimization purposes only. This will enable a client of the stackmap to reason about the registers it can use and which registers need to be preserved. Reviewed by Andy git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197317 91177308-0d34-0410-b5e6-96231b3b80d8
2013-12-14 06:53:06 +00:00
void initializeStackMapLivenessPass(PassRegistry&);
MachineCombiner Pass for selecting faster instruction sequence - target independent framework When the DAGcombiner selects instruction sequences it could increase the critical path or resource len. For example, on arm64 there are multiply-accumulate instructions (madd, msub). If e.g. the equivalent multiply-add sequence is not on the crictial path it makes sense to select it instead of the combined, single accumulate instruction (madd/msub). The reason is that the conversion from add+mul to the madd could lengthen the critical path by the latency of the multiply. But the DAGCombiner would always combine and select the madd/msub instruction. This patch uses machine trace metrics to estimate critical path length and resource length of an original instruction sequence vs a combined instruction sequence and picks the faster code based on its estimates. This patch only commits the target independent framework that evaluates and selects code sequences. The machine instruction combiner is turned off for all targets and expected to evolve over time by gradually handling DAGCombiner pattern in the target specific code. This framework lays the groundwork for fixing rdar://16319955 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214666 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-03 21:35:39 +00:00
void initializeMachineCombinerPass(PassRegistry &);
Add LoadCombine pass. This pass is disabled by default. Use -combine-loads to enable in -O[1-3] Differential revision: http://reviews.llvm.org/D3580 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209791 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-29 01:55:07 +00:00
void initializeLoadCombinePass(PassRegistry&);
Transform: add SymbolRewriter pass This introduces the symbol rewriter. This is an IR->IR transformation that is implemented as a CodeGenPrepare pass. This allows for the transparent adjustment of the symbols during compilation. It provides a clean, simple, elegant solution for symbol inter-positioning. This technique is often used, such as in the various sanitizers and performance analysis. The control of this is via a custom YAML syntax map file that indicates source to destination mapping, so as to avoid having the compiler to know the exact details of the source to destination transformations. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221548 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-07 21:32:08 +00:00
void initializeRewriteSymbolsPass(PassRegistry&);
Add a Windows EH preparation pass that zaps resumes If the personality is not a recognized MSVC personality function, this pass delegates to the dwarf EH preparation pass. This chaining supports people on *-windows-itanium or *-windows-gnu targets. Currently this recognizes some personalities used by MSVC and turns resume instructions into traps to avoid link errors. Even if cleanups are not used in the source program, LLVM requires the frontend to emit a code path that resumes unwinding after an exception. Clang does this, and we get unreachable resume instructions. PR20300 covers cleaning up these unreachable calls to resume. Reviewers: majnemer Differential Revision: http://reviews.llvm.org/D7216 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227405 91177308-0d34-0410-b5e6-96231b3b80d8
2015-01-29 00:41:44 +00:00
void initializeWinEHPreparePass(PassRegistry&);
Add the header that I accidentally forgot from r115900. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@115901 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-07 04:17:38 +00:00
}
#endif
Reference in New Issue Copy Permalink