6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2024-12-15 04:30:12 +00:00
Code Issues Projects Releases Wiki Activity
f8aad6c1ef
llvm-6502/include/llvm/InitializePasses.h

306 lines
14 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&);
[BDCE] Add a bit-tracking DCE pass BDCE is a bit-tracking dead code elimination pass. It is based on ADCE (the "aggressive DCE" pass), with the added capability to track dead bits of integer valued instructions and remove those instructions when all of the bits are dead. Currently, it does not actually do this all-bits-dead removal, but rather replaces the instruction's uses with a constant zero, and lets instcombine (and the later run of ADCE) do the rest. Because we essentially get a run of ADCE "for free" while tracking the dead bits, we also do what ADCE does and removes actually-dead instructions as well (this includes instructions newly trivially dead because all bits were dead, but not all such instructions can be removed). The motivation for this is a case like: int __attribute__((const)) foo(int i); int bar(int x) { x |= (4 & foo(5)); x |= (8 & foo(3)); x |= (16 & foo(2)); x |= (32 & foo(1)); x |= (64 & foo(0)); x |= (128& foo(4)); return x >> 4; } As it turns out, if you order the bit-field insertions so that all of the dead ones come last, then instcombine will remove them. However, if you pick some other order (such as the one above), the fact that some of the calls to foo() are useless is not locally obvious, and we don't remove them (without this pass). I did a quick compile-time overhead check using sqlite from the test suite (Release+Asserts). BDCE took ~0.4% of the compilation time (making it about twice as expensive as ADCE). I've not looked at why yet, but we eliminate instructions due to having all-dead bits in: External/SPEC/CFP2006/447.dealII/447.dealII External/SPEC/CINT2006/400.perlbench/400.perlbench External/SPEC/CINT2006/403.gcc/403.gcc MultiSource/Applications/ClamAV/clamscan MultiSource/Benchmarks/7zip/7zip-benchmark git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229462 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-17 01:36:59 +00:00
void initializeBDCEPass(PassRegistry&);
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 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&);
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&);
Divergence analysis for GPU programs Summary: Some optimizations such as jump threading and loop unswitching can negatively affect performance when applied to divergent branches. The divergence analysis added in this patch conservatively estimates which branches in a GPU program can diverge. This information can then help LLVM to run certain optimizations selectively. Test Plan: test/Analysis/DivergenceAnalysis/NVPTX/diverge.ll Reviewers: resistor, hfinkel, eliben, meheff, jholewinski Subscribers: broune, bjarke.roune, madhur13490, tstellarAMD, dberlin, echristo, jholewinski, llvm-commits Differential Revision: http://reviews.llvm.org/D8576 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234567 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-10 05:03:50 +00:00
void initializeDivergenceAnalysisPass(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&);
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 pass "Loop Interchange" This pass interchanges loops to provide a more cache-friendly memory access. For e.g. given a loop like - for(int i=0;i<N;i++) for(int j=0;j<N;j++) A[j][i] = A[j][i]+B[j][i]; is interchanged to - for(int j=0;j<N;j++) for(int i=0;i<N;i++) A[j][i] = A[j][i]+B[j][i]; This pass is currently disabled by default. To give a brief introduction it consists of 3 stages- LoopInterchangeLegality : Checks the legality of loop interchange based on Dependency matrix. LoopInterchangeProfitability: A very basic heuristic has been added to check for profitibility. This will evolve over time. LoopInterchangeTransform : Which does the actual transform. LNT Performance tests shows improvement in Polybench/linear-algebra/kernels/mvt and Polybench/linear-algebra/kernels/gemver becnmarks. TODO: 1) Add support for reductions and lcssa phi. 2) Improve profitability model. 3) Improve loop selection algorithm to select best loop for interchange. Currently the innermost loop is selected for interchange. 4) Improve compile time regression found in llvm lnt due to this pass. 5) Fix issues in Dependency Analysis module. A special thanks to Hal for reviewing this code. Review: http://reviews.llvm.org/D7499 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231458 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-06 10:11:25 +00:00
void initializeLoopInterchangePass(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 bitset metadata format and bitset lowering pass. This patch introduces a new mechanism that allows IR modules to co-operatively build pointer sets corresponding to addresses within a given set of globals. One particular use case for this is to allow a C++ program to efficiently verify (at each call site) that a vtable pointer is in the set of valid vtable pointers for the class or its derived classes. One way of doing this is for a toolchain component to build, for each class, a bit set that maps to the memory region allocated for the vtables, such that each 1 bit in the bit set maps to a valid vtable for that class, and lay out the vtables next to each other, to minimize the total size of the bit sets. The patch introduces a metadata format for representing pointer sets, an '@llvm.bitset.test' intrinsic and an LTO lowering pass that lays out the globals and builds the bitsets, and documents the new feature. Differential Revision: http://reviews.llvm.org/D7288 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230054 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-20 20:30:47 +00:00
void initializeLowerBitSetsPass(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&);
Introduce print-memderefs to test isDereferenceablePointer Since testing the function indirectly is tricky, introduce a direct print-memderefs pass, in the same spirit as print-memdeps, which prints dereferenceability information matched by FileCheck. Differential Revision: http://reviews.llvm.org/D7075 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228369 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-06 01:46:42 +00:00
void initializeMemDerefPrinterPass(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 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&);
Simplify n-ary adds by reassociation Summary: This transformation reassociates a n-ary add so that the add can partially reuse existing instructions. For example, this pass can simplify void foo(int a, int b) { bar(a + b); bar((a + 2) + b); } to void foo(int a, int b) { int t = a + b; bar(t); bar(t + 2); } saving one add instruction. Fixes PR22357 (https://llvm.org/bugs/show_bug.cgi?id=22357). Test Plan: nary-add.ll Reviewers: broune, dberlin, hfinkel, meheff, sanjoy, atrick Reviewed By: sanjoy, atrick Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8950 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@234855 91177308-0d34-0410-b5e6-96231b3b80d8
2015-04-14 04:59:22 +00:00
void initializeNaryReassociatePass(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 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&);
Add a pass for constructing gc.statepoint sequences w/explicit relocations This patch consists of a single pass whose only purpose is to visit previous inserted gc.statepoints which do not have gc.relocates inserted yet, and insert them. This can be used either immediately after IR generation to perform 'early safepoint insertion' or late in the pass order to perform 'late insertion'. This patch is setting the stage for work to continue in tree. In particular, there are known naming and style violations in the current patch. I'll try to get those resolved over the next week or so. As I touch each area to make style changes, I need to make sure we have adequate testing in place. As part of the cleanup, I will be cleaning up a collection of test cases we have out of tree and submitting them upstream. The tests included in this change are very basic and mostly to provide examples of usage. The pass has several main subproblems it needs to address: - First, it has identify any live pointers. In the current code, the use of address spaces to distinguish pointers to GC managed objects is hard coded, but this will become parametrizable in the near future. Note that the current change doesn't actually contain a useful liveness analysis. It was seperated into a followup change as the code wasn't ready to be shared. Instead, the current implementation just considers any dominating def of appropriate pointer type to be live. - Second, it has to identify base pointers for each live pointer. This is a fairly straight forward data flow algorithm. - Third, the information in the previous steps is used to actually introduce rewrites. Rather than trying to do this by hand, we simply re-purpose the code behind Mem2Reg to do this for us. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229945 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-20 01:06:44 +00:00
void initializeRewriteStatepointsForGCPass(PassRegistry&);
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 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&);
[ShrinkWrap] Add (a simplified version) of shrink-wrapping. This patch introduces a new pass that computes the safe point to insert the prologue and epilogue of the function. The interest is to find safe points that are cheaper than the entry and exits blocks. As an example and to avoid regressions to be introduce, this patch also implements the required bits to enable the shrink-wrapping pass for AArch64. ** Context ** Currently we insert the prologue and epilogue of the method/function in the entry and exits blocks. Although this is correct, we can do a better job when those are not immediately required and insert them at less frequently executed places. The job of the shrink-wrapping pass is to identify such places. ** Motivating example ** Let us consider the following function that perform a call only in one branch of a if: define i32 @f(i32 %a, i32 %b) { %tmp = alloca i32, align 4 %tmp2 = icmp slt i32 %a, %b br i1 %tmp2, label %true, label %false true: store i32 %a, i32* %tmp, align 4 %tmp4 = call i32 @doSomething(i32 0, i32* %tmp) br label %false false: %tmp.0 = phi i32 [ %tmp4, %true ], [ %a, %0 ] ret i32 %tmp.0 } On AArch64 this code generates (removing the cfi directives to ease readabilities): _f: ; @f ; BB#0: stp x29, x30, [sp, #-16]! mov x29, sp sub sp, sp, #16 ; =16 cmp w0, w1 b.ge LBB0_2 ; BB#1: ; %true stur w0, [x29, #-4] sub x1, x29, #4 ; =4 mov w0, wzr bl _doSomething LBB0_2: ; %false mov sp, x29 ldp x29, x30, [sp], #16 ret With shrink-wrapping we could generate: _f: ; @f ; BB#0: cmp w0, w1 b.ge LBB0_2 ; BB#1: ; %true stp x29, x30, [sp, #-16]! mov x29, sp sub sp, sp, #16 ; =16 stur w0, [x29, #-4] sub x1, x29, #4 ; =4 mov w0, wzr bl _doSomething add sp, x29, #16 ; =16 ldp x29, x30, [sp], #16 LBB0_2: ; %false ret Therefore, we would pay the overhead of setting up/destroying the frame only if we actually do the call. ** Proposed Solution ** This patch introduces a new machine pass that perform the shrink-wrapping analysis (See the comments at the beginning of ShrinkWrap.cpp for more details). It then stores the safe save and restore point into the MachineFrameInfo attached to the MachineFunction. This information is then used by the PrologEpilogInserter (PEI) to place the related code at the right place. This pass runs right before the PEI. Unlike the original paper of Chow from PLDI’88, this implementation of shrink-wrapping does not use expensive data-flow analysis and does not need hack to properly avoid frequently executed point. Instead, it relies on dominance and loop properties. The pass is off by default and each target can opt-in by setting the EnableShrinkWrap boolean to true in their derived class of TargetPassConfig. This setting can also be overwritten on the command line by using -enable-shrink-wrap. Before you try out the pass for your target, make sure you properly fix your emitProlog/emitEpilog/adjustForXXX method to cope with basic blocks that are not necessarily the entry block. ** Design Decisions ** 1. ShrinkWrap is its own pass right now. It could frankly be merged into PEI but for debugging and clarity I thought it was best to have its own file. 2. Right now, we only support one save point and one restore point. At some point we can expand this to several save point and restore point, the impacted component would then be: - The pass itself: New algorithm needed. - MachineFrameInfo: Hold a list or set of Save/Restore point instead of one pointer. - PEI: Should loop over the save point and restore point. Anyhow, at least for this first iteration, I do not believe this is interesting to support the complex cases. We should revisit that when we motivating examples. Differential Revision: http://reviews.llvm.org/D9210 <rdar://problem/3201744> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@236507 91177308-0d34-0410-b5e6-96231b3b80d8
2015-05-05 17:38:16 +00:00
void initializeShrinkWrapPass(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 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 a speculative execution pass Summary: This is a pass for speculative execution of instructions for simple if-then (triangle) control flow. It's aimed at GPUs, but could perhaps be used in other contexts. Enabling this pass gives us a 1.0% geomean improvement on Google benchmark suites, with one benchmark improving 33%. Credit goes to Jingyue Wu for writing an earlier version of this pass. Patched by Bjarke Roune. Test Plan: This patch adds a set of tests in test/Transforms/SpeculativeExecution/spec.ll The pass is controlled by a flag which defaults to having the pass not run. Reviewers: eliben, dberlin, meheff, jingyue, hfinkel Reviewed By: jingyue, hfinkel Subscribers: majnemer, jholewinski, llvm-commits Differential Revision: http://reviews.llvm.org/D9360 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@237459 91177308-0d34-0410-b5e6-96231b3b80d8
2015-05-15 17:54:48 +00:00
void initializeSpeculativeExecutionPass(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&);
Add straight-line strength reduction to LLVM Summary: Straight-line strength reduction (SLSR) is implemented in GCC but not yet in LLVM. It has proven to effectively simplify statements derived from an unrolled loop, and can potentially benefit many other cases too. For example, LLVM unrolls #pragma unroll foo (int i = 0; i < 3; ++i) { sum += foo((b + i) * s); } into sum += foo(b * s); sum += foo((b + 1) * s); sum += foo((b + 2) * s); However, no optimizations yet reduce the internal redundancy of the three expressions: b * s (b + 1) * s (b + 2) * s With SLSR, LLVM can optimize these three expressions into: t1 = b * s t2 = t1 + s t3 = t2 + s This commit is only an initial step towards implementing a series of such optimizations. I will implement more (see TODO in the file commentary) in the near future. This optimization is enabled for the NVPTX backend for now. However, I am more than happy to push it to the standard optimization pipeline after more thorough performance tests. Test Plan: test/StraightLineStrengthReduce/slsr.ll Reviewers: eliben, HaoLiu, meheff, hfinkel, jholewinski, atrick Reviewed By: jholewinski, atrick Subscribers: karthikthecool, jholewinski, llvm-commits Differential Revision: http://reviews.llvm.org/D7310 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228016 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-03 19:37:06 +00:00
void initializeStraightLineStrengthReducePass(PassRegistry &);
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 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&);
[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 &);
Revert "Reformat." This reverts commit r229651. I'd like to ultimately revert r229650 but this reformat stands in the way. I'll reformat the affected files once the the loop-access pass is fully committed. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229889 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-19 19:14:34 +00:00
void initializeTwoAddressInstructionPassPass(PassRegistry&);
void initializeTypeBasedAliasAnalysisPass(PassRegistry&);
void initializeScopedNoAliasAAPass(PassRegistry&);
void initializeUnifyFunctionExitNodesPass(PassRegistry&);
void initializeUnreachableBlockElimPass(PassRegistry&);
void initializeUnreachableMachineBlockElimPass(PassRegistry&);
void initializeVerifierLegacyPassPass(PassRegistry&);
void initializeVirtRegMapPass(PassRegistry&);
void initializeVirtRegRewriterPass(PassRegistry&);
void initializeInstSimplifierPass(PassRegistry&);
void initializeUnpackMachineBundlesPass(PassRegistry&);
void initializeFinalizeMachineBundlesPass(PassRegistry&);
[LoopAccesses] Create the analysis pass This is a function pass that runs the analysis on demand. The analysis can be initiated by querying the loop access info via LAA::getInfo. It either returns the cached info or runs the analysis. Symbolic stride information continues to reside outside of this analysis pass. We may move it inside later but it's not a priority for me right now. The idea is that Loop Distribution won't support run-time stride checking at least initially. This means that when querying the analysis, symbolic stride information can be provided optionally. Whether stride information is used can invalidate the cache entry and rerun the analysis. Note that if the loop does not have any symbolic stride, the entry should be preserved across Loop Distribution and LV. Since currently the only user of the pass is LV, I just check that the symbolic stride information didn't change when using a cached result. On the LV side, LoopVectorizationLegality requests the info object corresponding to the loop from the analysis pass. A large chunk of the diff is due to LAI becoming a pointer from a reference. A test will be added as part of the -analyze patch. Also tested that with AVX, we generate identical assembly output for the testsuite (including the external testsuite) before and after. This is part of the patchset that converts LoopAccessAnalysis into an actual analysis pass. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229893 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-19 19:15:04 +00:00
void initializeLoopAccessAnalysisPass(PassRegistry&);
Revert "Reformat." This reverts commit r229651. I'd like to ultimately revert r229650 but this reformat stands in the way. I'll reformat the affected files once the the loop-access pass is fully committed. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229889 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-19 19:14:34 +00:00
void initializeLoopVectorizePass(PassRegistry&);
void initializeSLPVectorizerPass(PassRegistry&);
void initializeBBVectorizePass(PassRegistry&);
void initializeMachineFunctionPrinterPassPass(PassRegistry&);
Resubmit r237954 (MIR Serialization: print and parse LLVM IR using MIR format). This commit a 3rd attempt at comitting the initial MIR serialization patch. The first commit (r237708) was reverted in 237730. Then the second commit (r237954) was reverted in r238007, as the MIR library under CodeGen caused a circular dependency where the CodeGen library depended on MIR and MIR library depended on CodeGen. This commit has fixed the dependencies between CodeGen and MIR by reorganizing the MIR serialization code - the code that prints out MIR has been moved to CodeGen, and the MIR library has been renamed to MIRParser. Now the CodeGen library doesn't depend on the MIRParser library, thus the circular dependency no longer exists. --Original Commit Message-- MIR Serialization: print and parse LLVM IR using MIR format. This commit is the initial commit for the MIR serialization project. It creates a new library under CodeGen called 'MIR'. This new library adds a new machine function pass that prints out the LLVM IR using the MIR format. This pass is then added as a last pass when a 'stop-after' option is used in llc. The new library adds the initial functionality for parsing of MIR files as well. This commit also extends the llc tool so that it can recognize and parse MIR input files. Reviewers: Duncan P. N. Exon Smith, Matthias Braun, Philip Reames Differential Revision: http://reviews.llvm.org/D9616 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238341 91177308-0d34-0410-b5e6-96231b3b80d8
2015-05-27 18:02:19 +00:00
void initializeMIRPrintingPassPass(PassRegistry&);
Revert "Reformat." This reverts commit r229651. I'd like to ultimately revert r229650 but this reformat stands in the way. I'll reformat the affected files once the the loop-access pass is fully committed. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229889 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-19 19:14:34 +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 a pass for inserting safepoints into (nearly) arbitrary IR This pass is responsible for figuring out where to place call safepoints and safepoint polls. It doesn't actually make the relocations explicit; that's the job of the RewriteStatepointsForGC pass (http://reviews.llvm.org/D6975). Note that this code is not yet finalized. Its moving in tree for incremental development, but further cleanup is needed and will happen over the next few days. It is not yet part of the standard pass order. Planned changes in the near future: - I plan on restructuring the statepoint rewrite to use the functions add to the IRBuilder a while back. - In the current pass, the function "gc.safepoint_poll" is treated specially but is not an intrinsic. I plan to make identifying the poll function a property of the GCStrategy at some point in the near future. - As follow on patches, I will be separating a collection of test cases we have out of tree and submitting them upstream. - It's not explicit in the code, but these two patches are introducing a new state for a statepoint which looks a lot like a patchpoint. There's no a transient form which doesn't yet have the relocations explicitly represented, but does prevent reordering of memory operations. Once this is in, I need to update actually make this explicit by reserving the 'unused' argument of the statepoint as a flag, updating the docs, and making the code explicitly check for such a thing. This wasn't really planned, but once I split the two passes - which was done for other reasons - the intermediate state fell out. Just reminds us once again that we need to merge statepoints and patchpoints at some point in the not that distant future. Future directions planned: - Identifying more cases where a backedge safepoint isn't required to ensure timely execution of a safepoint poll. - Tweaking the insertion process to generate easier to optimize IR. (For example, investigating making SplitBackedge) the default. - Adding opt-in flags for a GCStrategy to use this pass. Once done, add this pass to the actual pass ordering. Differential Revision: http://reviews.llvm.org/D6981 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228090 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-04 00:37:33 +00:00
void initializePlaceBackedgeSafepointsImplPass(PassRegistry&);
void initializePlaceSafepointsPass(PassRegistry&);
Add an IR-to-IR test for dwarf EH preparation using opt This tests the simple resume instruction elimination logic that we have before making some changes to it. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@229768 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-18 23:17:41 +00:00
void initializeDwarfEHPreparePass(PassRegistry&);
Reapply r233175 and r233183: float2int. This re-adds float2int to the tree, after fixing PR23038. It turns out the argument to APSInt() is true-if-unsigned, rather than true-if-signed :(. Added testcase and explanatory comment. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233370 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-27 10:36:57 +00:00
void initializeFloat2IntPass(PassRegistry&);
New Loop Distribution pass Summary: This implements the initial version as was proposed earlier this year (http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-January/080462.html). Since then Loop Access Analysis was split out from the Loop Vectorizer and was made into a separate analysis pass. Loop Distribution becomes the second user of this analysis. The pass is off by default and can be enabled with -enable-loop-distribution. There is currently no notion of profitability; if there is a loop with dependence cycles, the pass will try to split them off from other memory operations into a separate loop. I decided to remove the control-dependence calculation from this first version. This and the issues with the PDT are actively discussed so it probably makes sense to treat it separately. Right now I just mark all terminator instruction required which keeps identical CFGs for each distributed loop. This seems to be working pretty well for 456.hmmer where even though there is an empty if-then block in the distributed loop initially, it gets completely removed. The pass keeps DominatorTree and LoopInfo updated. I've tested this with -loop-distribute-verify with the testsuite where we distribute ~90 loops. SimplifyLoop is violated in some cases and I have a FIXME covering this. Reviewers: hfinkel, nadav, aschwaighofer Reviewed By: aschwaighofer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D8831 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@237358 91177308-0d34-0410-b5e6-96231b3b80d8
2015-05-14 12:05:18 +00:00
void initializeLoopDistributePass(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