summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Passes
Commit message (Collapse)AuthorAgeFilesLines
...
* [New PM][IRCE] port of Inductive Range Check Elimination pass to the new ↵Fedor Sergeev2018-03-152-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | pass manager There are two nontrivial details here: * Loop structure update interface is quite different with new pass manager, so the code to add new loops was factored out * BranchProbabilityInfo is not a loop analysis, so it can not be just getResult'ed from within the loop pass. It cant even be queried through getCachedResult as LoopCanonicalization sequence (e.g. LoopSimplify) might invalidate BPI results. Complete solution for BPI will likely take some time to discuss and figure out, so for now this was partially solved by making BPI optional in IRCE (skipping a couple of profitability checks if it is absent). Most of the IRCE tests got their corresponding new-pass-manager variant enabled. Only two of them depend on BPI, both marked with TODO, to be turned on when BPI starts being available for loop passes. Reviewers: chandlerc, mkazantsev, sanjoy, asbirlea Reviewed By: mkazantsev Differential Revision: https://reviews.llvm.org/D43795 llvm-svn: 327619
* Remove the LoopInstSimplify pass (-loop-instsimplify)Vedant Kumar2018-03-122-5/+2
| | | | | | | | | | | | LoopInstSimplify is unused and untested. Reading through the commit history the pass also seems to have a high maintenance burden. It would be best to retire the pass for now. It should be easy to recover if we need something similar in the future. Differential Revision: https://reviews.llvm.org/D44053 llvm-svn: 327329
* Another try to commit 323321 (aggressive instruction combine).Amjad Aboud2018-01-253-1/+7
| | | | llvm-svn: 323416
* Reverted 323321.Amjad Aboud2018-01-243-7/+1
| | | | llvm-svn: 323326
* [InstCombine] Introducing Aggressive Instruction Combine pass ↵Amjad Aboud2018-01-243-1/+7
| | | | | | | | | | | | | | | | | | (-aggressive-instcombine). Combine expression patterns to form expressions with fewer, simple instructions. This pass does not modify the CFG. For example, this pass reduce width of expressions post-dominated by TruncInst into smaller width when applicable. It differs from instcombine pass in that it contains pattern optimization that requires higher complexity than the O(1), thus, it should run fewer times than instcombine pass. Differential Revision: https://reviews.llvm.org/D38313 llvm-svn: 323321
* Fix typos of occurred and occurrenceMalcolm Parsons2018-01-241-1/+1
| | | | llvm-svn: 323318
* NewPM: Add an extension point for the start of the pipeline.David Blaikie2018-01-231-1/+8
| | | | | | | | | | This applies to most pipelines except the LTO and ThinLTO backend actions - it is for use at the beginning of the overall pipeline. This extension point will be used to add the GCOV pass when enabled in Clang. llvm-svn: 323166
* Add a pass to generate synthetic function entry counts.Easwaran Raman2018-01-092-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This pass synthesizes function entry counts by traversing the callgraph and using the relative block frequencies of the callsites. The intended use of these counts is in inlining to determine hot/cold callsites in the absence of profile information. The pass is split into two files with the code that propagates the counts in a callgraph in a Utils file. I plan to add support for propagation in the thinlto link phase and the propagation code will be shared and hence this split. I did not add support to the old PM since hot callsite determination in inlining is not possible in old PM (although we could use hot callee heuristic with synthetic counts in the old PM it is not worth the effort tuning it) Reviewers: davidxl, silvas Subscribers: mgorny, mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D41604 llvm-svn: 322110
* [PM] pass -debug-pass-manager flag into FunctionToLoopPassAdaptor's ↵Fedor Sergeev2017-12-291-7/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | canonicalization PM Summary: New pass manager driver passes DebugPM (-debug-pass-manager) flag into individual PassManager constructors in order to enable debug logging. FunctionToLoopPassAdaptor has its own internal LoopCanonicalizationPM which never gets its debug logging enabled and that means canonicalization passes like LoopSimplify are never present in -debug-pass-manager output. Extending FunctionToLoopPassAdaptor's constructor and createFunctionToLoopPassAdaptor wrapper with an optional boolean DebugLogging argument. Passing debug-logging flags there as appropriate. Reviewers: chandlerc, davide Reviewed By: davide Subscribers: mehdi_amini, eraman, llvm-commits, JDevlieghere Differential Revision: https://reviews.llvm.org/D41586 llvm-svn: 321548
* (Re-landing) Expose a TargetMachine::getTargetTransformInfo functionSanjoy Das2017-12-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Re-land r321234. It had to be reverted because it broke the shared library build. The shared library build broke because there was a missing LLVMBuild dependency from lib/Passes (which calls TargetMachine::getTargetIRAnalysis) to lib/Target. As far as I can tell, this problem was always there but was somehow masked before (perhaps because TargetMachine::getTargetIRAnalysis was a virtual function). Original commit message: This makes the TargetMachine interface a bit simpler. We still need the std::function in TargetIRAnalysis to avoid having to add a dependency from Analysis to Target. See discussion: http://lists.llvm.org/pipermail/llvm-dev/2017-December/119749.html I avoided adding all of the backend owners to this review since the change is simple, but let me know if you feel differently about this. Reviewers: echristo, MatzeB, hfinkel Reviewed By: hfinkel Subscribers: jholewinski, jfb, arsenm, dschuff, mcrosier, sdardis, nemanjai, nhaehnle, javed.absar, sbc100, jgravelle-google, aheejin, kbarton, llvm-commits Differential Revision: https://reviews.llvm.org/D41464 llvm-svn: 321375
* [PM] port Rewrite Statepoints For GC to the new pass manager.Fedor Sergeev2017-12-152-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The port is nearly straightforward. The only complication is related to the analyses handling, since one of the analyses used in this module pass is domtree, which is a function analysis. That requires asking for the results of each function and disallows a single interface for run-on-module pass action. Decided to copy-paste the main body of this pass. Most of its code is requesting analyses anyway, so not that much of a copy-paste. The rest of the code movement is to transform all the implementation helper functions like stripNonValidData into non-member statics. Extended all the related LLVM tests with new-pass-manager use. No failures. Reviewers: sanjoy, anna, reames Reviewed By: anna Subscribers: skatkov, llvm-commits Differential Revision: https://reviews.llvm.org/D41162 llvm-svn: 320796
* [SimplifyCFG] don't sink common insts too soon (PR34603)Sanjay Patel2017-12-141-8/+11
| | | | | | | | | | | | This should solve: https://bugs.llvm.org/show_bug.cgi?id=34603 ...by preventing SimplifyCFG from altering redundant instructions before early-cse has a chance to run. It changes the default (canonical-forming) behavior of SimplifyCFG, so we're only doing the sinking transform later in the optimization pipeline. Differential Revision: https://reviews.llvm.org/D38566 llvm-svn: 320749
* Remove redundant includes from various places.Michael Zolotukhin2017-12-131-3/+0
| | | | llvm-svn: 320629
* Add a new pass to speculate around PHI nodes with constant (integer) ↵Chandler Carruth2017-11-282-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | operands when profitable. The core idea is to (re-)introduce some redundancies where their cost is hidden by the cost of materializing immediates for constant operands of PHI nodes. When the cost of the redundancies is covered by this, avoiding materializing the immediate has numerous benefits: 1) Less register pressure 2) Potential for further folding / combining 3) Potential for more efficient instructions due to immediate operand As a motivating example, consider the remarkably different cost on x86 of a SHL instruction with an immediate operand versus a register operand. This pattern turns up surprisingly frequently, but is somewhat rarely obvious as a significant performance problem. The pass is entirely target independent, but it does rely on the target cost model in TTI to decide when to speculate things around the PHI node. I've included x86-focused tests, but any target that sets up its immediate cost model should benefit from this pass. There is probably more that can be done in this space, but the pass as-is is enough to get some important performance on our internal benchmarks, and should be generally performance neutral, but help with more extensive benchmarking is always welcome. One awkward part is that this pass has to be scheduled after *everything* that can eliminate these kinds of redundancies. This includes SimplifyCFG, GVN, etc. I'm open to suggestions about better places to put this. We could in theory make it part of the codegen pass pipeline, but there doesn't really seem to be a good reason for that -- it isn't "lowering" in any sense and only relies on pretty standard cost model based TTI queries, so it seems to fit well with the "optimization" pipeline model. Still, further thoughts on the pipeline position are welcome. I've also only implemented this in the new pass manager. If folks are very interested, I can try to add it to the old PM as well, but I didn't really see much point (my use case is already switched over to the new PM). I've tested this pretty heavily without issue. A wide range of benchmarks internally show no change outside the noise, and I don't see any significant changes in SPEC either. However, the size class computation in tcmalloc is substantially improved by this, which turns into a 2% to 4% win on the hottest path through tcmalloc for us, so there are definitely important cases where this is going to make a substantial difference. Differential revision: https://reviews.llvm.org/D37467 llvm-svn: 319164
* [(new) Pass Manager] instantiate SimplifyCFG with the same options as the old PMSanjay Patel2017-11-151-2/+7
| | | | | | | | | | | | | | | | | | This is a recommit of r316869 which was speculatively reverted with r317444 and subsequently shown to not be the cause of PR35210. That crash should be fixed after r318237. Original commit message: The old PM sets the options of what used to be known as "latesimplifycfg" on the instantiation after the vectorizers have run, so that's what we'redoing here. FWIW, there's a later SimplifyCFGPass instantiation in both PMs where we do not set the "late" options. I'm not sure if that's intentional or not. Differential Revision: https://reviews.llvm.org/D39407 llvm-svn: 318299
* Rename CountingFunctionInserter and use for both mcount and cygprofile ↵Hans Wennborg2017-11-142-0/+3
| | | | | | | | | | | | | | | | | | | | | | calls, before and after inlining Clang implements the -finstrument-functions flag inherited from GCC, which inserts calls to __cyg_profile_func_{enter,exit} on function entry and exit. This is useful for getting a trace of how the functions in a program are executed. Normally, the calls remain even if a function is inlined into another function, but it is useful to be able to turn this off for users who are interested in a lower-level trace, i.e. one that reflects what functions are called post-inlining. (We use this to generate link order files for Chromium.) LLVM already has a pass for inserting similar instrumentation calls to mcount(), which it does after inlining. This patch renames and extends that pass to handle calls both to mcount and the cygprofile functions, before and/or after inlining as controlled by function attributes. Differential Revision: https://reviews.llvm.org/D39287 llvm-svn: 318195
* [PM] Port BoundsChecking to the new PM.Chandler Carruth2017-11-142-0/+2
| | | | | | | | | | | Registers it and everything, updates all the references, etc. Next patch will add support to Clang's `-fexperimental-new-pass-manager` path to actually enable BoundsChecking correctly. Differential Revision: https://reviews.llvm.org/D39084 llvm-svn: 318128
* [PassManager, SimplifyCFG] Revert r316908 and r316869.David L. Jones2017-11-061-7/+2
| | | | | | These cause Clang to crash with a segfault. See PR35210 for details. llvm-svn: 317444
* Recommit r317351 : Add CallSiteSplitting passJun Bum Lim2017-11-032-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This recommit r317351 after fixing a buildbot failure. Original commit message: Summary: This change add a pass which tries to split a call-site to pass more constrained arguments if its argument is predicated in the control flow so that we can expose better context to the later passes (e.g, inliner, jump threading, or IPA-CP based function cloning, etc.). As of now we support two cases : 1) If a call site is dominated by an OR condition and if any of its arguments are predicated on this OR condition, try to split the condition with more constrained arguments. For example, in the code below, we try to split the call site since we can predicate the argument (ptr) based on the OR condition. Split from : if (!ptr || c) callee(ptr); to : if (!ptr) callee(null ptr) // set the known constant value else if (c) callee(nonnull ptr) // set non-null attribute in the argument 2) We can also split a call-site based on constant incoming values of a PHI For example, from : BB0: %c = icmp eq i32 %i1, %i2 br i1 %c, label %BB2, label %BB1 BB1: br label %BB2 BB2: %p = phi i32 [ 0, %BB0 ], [ 1, %BB1 ] call void @bar(i32 %p) to BB0: %c = icmp eq i32 %i1, %i2 br i1 %c, label %BB2-split0, label %BB1 BB1: br label %BB2-split1 BB2-split0: call void @bar(i32 0) br label %BB2 BB2-split1: call void @bar(i32 1) br label %BB2 BB2: %p = phi i32 [ 0, %BB2-split0 ], [ 1, %BB2-split1 ] llvm-svn: 317362
* Revert "Add CallSiteSplitting pass"Jun Bum Lim2017-11-032-9/+1
| | | | | | | | Revert due to Buildbot failure. This reverts commit r317351. llvm-svn: 317353
* Add CallSiteSplitting passJun Bum Lim2017-11-032-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change add a pass which tries to split a call-site to pass more constrained arguments if its argument is predicated in the control flow so that we can expose better context to the later passes (e.g, inliner, jump threading, or IPA-CP based function cloning, etc.). As of now we support two cases : 1) If a call site is dominated by an OR condition and if any of its arguments are predicated on this OR condition, try to split the condition with more constrained arguments. For example, in the code below, we try to split the call site since we can predicate the argument (ptr) based on the OR condition. Split from : if (!ptr || c) callee(ptr); to : if (!ptr) callee(null ptr) // set the known constant value else if (c) callee(nonnull ptr) // set non-null attribute in the argument 2) We can also split a call-site based on constant incoming values of a PHI For example, from : BB0: %c = icmp eq i32 %i1, %i2 br i1 %c, label %BB2, label %BB1 BB1: br label %BB2 BB2: %p = phi i32 [ 0, %BB0 ], [ 1, %BB1 ] call void @bar(i32 %p) to BB0: %c = icmp eq i32 %i1, %i2 br i1 %c, label %BB2-split0, label %BB1 BB1: br label %BB2-split1 BB2-split0: call void @bar(i32 0) br label %BB2 BB2-split1: call void @bar(i32 1) br label %BB2 BB2: %p = phi i32 [ 0, %BB2-split0 ], [ 1, %BB2-split1 ] Reviewers: davidxl, huntergr, chandlerc, mcrosier, eraman, davide Reviewed By: davidxl Subscribers: sdesmalen, ashutosh.nema, fhahn, mssimpso, aemerson, mgorny, mehdi_amini, kristof.beyls, llvm-commits Differential Revision: https://reviews.llvm.org/D39137 llvm-svn: 317351
* [(new) Pass Manager] instantiate SimplifyCFG with the same options as the old PMSanjay Patel2017-10-291-2/+7
| | | | | | | | | | | | The old PM sets the options of what used to be known as "latesimplifycfg" on the instantiation after the vectorizers have run, so that's what we'redoing here. FWIW, there's a later SimplifyCFGPass instantiation in both PMs where we do not set the "late" options. I'm not sure if that's intentional or not. Differential Revision: https://reviews.llvm.org/D39407 llvm-svn: 316869
* Add CalledValuePropagation passMatthew Simpson2017-10-252-0/+10
| | | | | | | | | | | | | | This patch adds a new pass for attaching !callees metadata to indirect call sites. The pass propagates values to call sites by performing an IPSCCP-like analysis using the generic sparse propagation solver. For indirect call sites having a small set of possible callees, the attached metadata indicates what those callees are. The metadata can be used to facilitate optimizations like intersecting the function attributes of the possible callees, refining the call graph, performing indirect call promotion, etc. Differential Revision: https://reviews.llvm.org/D37355 llvm-svn: 316576
* [PM] Add pgo-memop-opt pass to the new pass managerRong Xu2017-10-231-0/+6
| | | | | | | | | This pass adds pgo-memop-opt pass to the new pass manager. It is in the old pass manager but somehow left out in the new pass manager. Differential Revision: http://reviews.llvm.org/D39145 llvm-svn: 316384
* Rename OptimizationDiagnosticInfo.* to OptimizationRemarkEmitter.*Adam Nemet2017-10-091-1/+1
| | | | | | | Sync it up with the name of the class actually defined here. This has been bothering me for a while... llvm-svn: 315249
* [NewPassManager] Run global dead code elimination after the inliner.Davide Italiano2017-10-051-0/+1
| | | | | | | | | This is the same exact change we did for the current pass manager in rL314997, but the new pass manager pipeline already happened to run GlobalOpt after the inliner, so we just insert a run of GDCE here. llvm-svn: 315003
* Separate the logic when handling indirect calls in SamplePGO ThinLTO compile ↵Dehao Chen2017-10-011-1/+2
| | | | | | | | | | | | | | | | phase and other phases. Summary: In SamplePGO ThinLTO compile phase, we will not invoke ICP as it may introduce confusion to the 2nd annotation. This patch extracted that logic and makes it clearer before profile annotation. In the mean time, we need to make function importing process both inlined callsites as well as not promoted indirect callsites. Reviewers: tejohnson Reviewed By: tejohnson Subscribers: sanjoy, mehdi_amini, llvm-commits, inglorion Differential Revision: https://reviews.llvm.org/D38094 llvm-svn: 314619
* [DivRempairs] add a pass to optimize div/rem pairs (PR31028)Sanjay Patel2017-09-092-0/+7
| | | | | | | | | | | | | | | | | | This is intended to be a superset of the functionality from D31037 (EarlyCSE) but implemented as an independent pass, so there's no stretching of scope and feature creep for an existing pass. I also proposed a weaker version of this for SimplifyCFG in D30910. And I initially had almost this same functionality as an addition to CGP in the motivating example of PR31028: https://bugs.llvm.org/show_bug.cgi?id=31028 The advantage of positioning this ahead of SimplifyCFG in the pass pipeline is that it can allow more flattening. But it needs to be after passes (InstCombine) that could sink a div/rem and undo the hoisting that is done here. Decomposing remainder may allow removing some code from the backend (PPC and possibly others). Differential Revision: https://reviews.llvm.org/D37121 llvm-svn: 312862
* [PM] Switch the CGSCC debug messages to use the standard LLVM debugChandler Carruth2017-08-111-7/+5
| | | | | | | | | | | | | | | | printing techniques with a DEBUG_TYPE controlling them. It was a mistake to start re-purposing the pass manager `DebugLogging` variable for generic debug printing -- those logs are intended to be very minimal and primarily used for testing. More detailed and comprehensive logging doesn't make sense there (it would only make for brittle tests). Moreover, we kept forgetting to propagate the `DebugLogging` variable to various places making it also ineffective and/or unavailable. Switching to `DEBUG_TYPE` makes this a non-issue. llvm-svn: 310695
* Revert part of r310296 to make it really NFC for instrumentation PGO.Dehao Chen2017-08-101-1/+1
| | | | | | | | | | | | | | Summary: Part of r310296 will disable PGOIndirectCallPromotion in ThinLTO backend if PGOOpt is None. However, as PGOOpt is not passed down to ThinLTO backend for instrumentation based PGO, that change would actually disable ICP entirely in ThinLTO backend, making it behave differently in instrumentation PGO mode. This change reverts that change, and only disable ICP there when it is SamplePGO. Reviewers: davidxl Reviewed By: davidxl Subscribers: sanjoy, mehdi_amini, eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D36566 llvm-svn: 310550
* Move the SampleProfileLoader right after EarlyFPM.Dehao Chen2017-08-071-20/+31
| | | | | | | | | | | | | | Summary: SampleProfileLoader pass do need to happen after some early cleanup passes so that inlining can happen correctly inside the SampleProfileLoader pass. Reviewers: chandlerc, davidxl, tejohnson Reviewed By: chandlerc, tejohnson Subscribers: sanjoy, mehdi_amini, eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D36333 llvm-svn: 310296
* [PM] Split LoopUnrollPass and make partial unroller a function passTeresa Johnson2017-08-022-4/+4
| | | | | | | | | | | | | | | | | | | | | | Summary: This is largely NFC*, in preparation for utilizing ProfileSummaryInfo and BranchFrequencyInfo analyses. In this patch I am only doing the splitting for the New PM, but I can do the same for the legacy PM as a follow-on if this looks good. *Not NFC since for partial unrolling we lose the updates done to the loop traversal (adding new sibling and child loops) - according to Chandler this is not very useful for partial unrolling, but it also means that the debugging flag -unroll-revisit-child-loops no longer works for partial unrolling. Reviewers: chandlerc Subscribers: mehdi_amini, mzolotukhin, eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D36157 llvm-svn: 309886
* Update the new PM pipeline to make ICP aware if it is SamplePGO build.Dehao Chen2017-08-021-21/+25
| | | | | | | | | | | | | | Summary: In ThinLTO backend compile, OPTOptions are not set so that the ICP in ThinLTO backend does not know if it is a SamplePGO build, in which profile count needs to be annotated directly on call instructions. This patch cleaned up the PGOOptions handling logic and passes down PGOOptions to ThinLTO backend. Reviewers: chandlerc, tejohnson, davidxl Reviewed By: chandlerc Subscribers: sanjoy, llvm-commits, mehdi_amini Differential Revision: https://reviews.llvm.org/D36052 llvm-svn: 309780
* Refactor the build{Module|Function}SimplificationPipeline to expose ↵Dehao Chen2017-07-301-18/+19
| | | | | | | | | | | | | | | | optimization phase. Summary: This is in preparation of https://reviews.llvm.org/D36052 Reviewers: chandlerc, davidxl, tejohnson Reviewed By: chandlerc Subscribers: sanjoy, llvm-commits Differential Revision: https://reviews.llvm.org/D36053 llvm-svn: 309500
* Refine the PGOOpt and SamplePGOSupport handling.Dehao Chen2017-07-291-7/+12
| | | | | | | | | | | | | | | | | | | Summary: Now that SamplePGOSupport is part of PGOOpt, there are several places that need tweaking: 1. AddDiscriminator pass should *not* be invoked at ThinLTOBackend (as it's already invoked in the PreLink phase) 2. addPGOInstrPasses should only be invoked when either ProfileGenFile or ProfileUseFile is non-empty. 3. SampleProfileLoaderPass should only be invoked when SampleProfileFile is non-empty. 4. PGOIndirectCallPromotion should only be invoked in ProfileUse phase, or in ThinLTOBackend of SamplePGO. Reviewers: chandlerc, tejohnson, davidxl Reviewed By: chandlerc Subscribers: sanjoy, mehdi_amini, eraman, llvm-commits Differential Revision: https://reviews.llvm.org/D36040 llvm-svn: 309478
* Update the assertion to meet with the changes in r309121. (NFC)Dehao Chen2017-07-261-1/+1
| | | | llvm-svn: 309125
* Make new PM honor -fdebug-info-for-profilingDehao Chen2017-07-261-0/+2
| | | | | | | | | | | | | | Summary: The new PM needs to invoke add-discriminator pass when building with -fdebug-info-for-profiling. Reviewers: chandlerc, davidxl Reviewed By: chandlerc Subscribers: sanjoy, llvm-commits Differential Revision: https://reviews.llvm.org/D35744 llvm-svn: 309121
* [PM] Enable registration of out-of-tree passes with PassBuilderPhilip Pfaffe2017-07-101-34/+187
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds a callback registration API to the PassBuilder, enabling registering out-of-tree passes with it. Through the Callback API, callers may register callbacks with the various stages at which passes are added into pass managers, including parsing of a pass pipeline as well as at extension points within the default -O pipelines. Registering utilities like `require<>` and `invalidate<>` needs to be handled manually by the caller, but a helper is provided. Additionally, adding passes at pipeline extension points is exposed through the opt tool. This patch adds a `-passes-ep-X` commandline option for every extension point X, which opt parses into pipelines inserted into that extension point. Reviewers: chandlerc Reviewed By: chandlerc Subscribers: lksbhm, grosser, davide, mehdi_amini, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D33464 llvm-svn: 307532
* Add sample PGO support to ThinLTO new pass manager.Dehao Chen2017-07-071-13/+28
| | | | | | | | | | | | | | | | | | | | | Summary: For SamplePGO + ThinLTO, because profile annotation is done twice at both PrepareForThinLTO pipeline and backend compiler, the following changes are needed at the PrepareForThinLTO phase to ensure the IR is not changed dramatically. Otherwise the profile annotation will be inaccurate in the backend compiler. * disable hot-caller heuristic * disable loop unrolling * disable indirect call promotion This will unblock the new PM testing for sample PGO (tools/clang/test/CodeGen/pgo-sample-thinlto-summary.c), which will be covered in another cfe patch. Reviewers: chandlerc, tejohnson, davidxl Reviewed By: tejohnson Subscribers: sanjoy, mehdi_amini, Prazek, inglorion, llvm-commits Differential Revision: https://reviews.llvm.org/D34895 llvm-svn: 307437
* Hook the sample PGO machinery in the new PMDehao Chen2017-06-291-9/+13
| | | | | | | | | | | | | | Summary: This patch hooks up SampleProfileLoaderPass with the new PM. Reviewers: chandlerc, davidxl, davide, tejohnson Reviewed By: chandlerc, tejohnson Subscribers: tejohnson, llvm-commits, sanjoy Differential Revision: https://reviews.llvm.org/D34720 llvm-svn: 306763
* [ThinkLTO] Invoke build(Thin)?LTOPreLinkDefaultPipeline.Tim Shen2017-06-291-3/+0
| | | | | | | | | | | | | Previously it doesn't actually invoke the designated new PM builder functions. This patch moves NameAnonGlobalPass out from PassBuilder, as Chandler points out that PassBuilder is used for non-O0 builds, and for optimizations only. Differential Revision: https://reviews.llvm.org/D34728 llvm-svn: 306756
* Create inliner params based on size and opt levels.Easwaran Raman2017-06-281-3/+11
| | | | | | Differential revision: https://reviews.llvm.org/D34309 llvm-svn: 306542
* [EarlyCSE][MemorySSA] Enable MemorySSA in function-simplification pass of ↵Geoff Berry2017-06-271-2/+2
| | | | | | EarlyCSE. llvm-svn: 306477
* [PGO] Implementate profile counter regiser promotionXinliang David Li2017-06-251-0/+5
| | | | | | Differential Revision: http://reviews.llvm.org/D34085 llvm-svn: 306231
* Remove the LoadCombine pass. It was never enabled and is unsupported.Eric Christopher2017-06-221-3/+0
| | | | | | Based on discussions with the author on mailing lists. llvm-svn: 306067
* [EarlyCSE] Add option to use MemorySSA for function simplification run of ↵Geoff Berry2017-06-101-1/+5
| | | | | | | | | | | | | | | | EarlyCSE (off by default). Summary: Use MemorySSA for memory dependency checking in the EarlyCSE pass at the start of the function simplification portion of the pipeline. We rely on the fact that GVNHoist runs just after this pass of EarlyCSE to amortize the MemorySSA construction cost since GVNHoist uses MemorySSA and EarlyCSE preserves it. This is turned off by default. A follow-up change will turn it on to allow for easier reversion in case it breaks something. llvm-svn: 305146
* [PM] Add GVNSink to the pipeline.Davide Italiano2017-06-031-0/+10
| | | | | | | | | With this, the two pipelines should be in sync again (modulo LoopUnswitch, but Chandler is actively working on that). Differential Revision: https://reviews.llvm.org/D33810 llvm-svn: 304671
* Move GVNHoist to the right position in the new pass manager pipeline.Davide Italiano2017-06-011-2/+4
| | | | | | | | | GVNHoist was moved as part of simplification passes for the current pass manager (but not for the new), so they're out-of-sync. Differential Revision: https://reviews.llvm.org/D33806 llvm-svn: 304490
* [PM/ThinLTO] Port the ThinLTO pipeline (both components) to the new PM.Chandler Carruth2017-06-011-18/+123
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Based on the original patch by Davide, but I've adjusted the API exposed to just be different entry points rather than exposing more state parameters. I've factored all the common logic out so that we don't have any duplicate pipelines, we just stitch them together in different ways. I think this makes the build easier to reason about and understand. This adds a direct method for getting the module simplification pipeline as well as a method to get the optimization pipeline. While not my express goal, this seems nice and gives a good place comment about the restrictions that are imposed on them. I did make some minor changes to the way the pipelines are structured here, but hopefully not ones that are significant or controversial: 1) I sunk the PGO indirect call promotion to only be run when we have PGO enabled (or as part of the special ThinLTO pipeline). 2) I made the extra GlobalOpt run in ThinLTO just happen all the time and at a slightly more powerful place (before we remove available externaly functions). This seems like general goodness and not a big compile time sink, so it didn't make sense to *only* use it in ThinLTO. Fewer differences in the pipeline makes everything simpler IMO. 3) I hoisted the ThinLTO stop point pre-link above the the RPO function attr inference. The RPO inference won't infer anything terribly meaningful pre-link (recursiveness?) so it didn't make a lot of sense. But if the placement of RPO inference starts to matter, we should move it to the canonicalization phase anyways which seems like a better place for it (and there is a FIXME to this effect!). But that seemed a bridge too far for this patch. If we ever need to parameterize these pipelines more heavily, we can always sink the logic to helper functions with parameters to keep those parameters out of the public API. But the changes above seemed minor that we could possible get away without the parameters entirely. I added support for parsing 'thinlto' and 'thinlto-pre-link' names in pass pipelines to make it easy to test these routines and play with them in larger pipelines. I also added a really basic manifest of passes test that will show exactly how the pipelines behave and work as well as making updates to them clear. Lastly, this factoring does introduce a nesting layer of module pass managers in the default pipeline. I don't think this is a big deal and the flexibility of decoupling the pipelines seems easily worth it. Differential Revision: https://reviews.llvm.org/D33540 llvm-svn: 304407
* [PM] Enable the new simple loop unswitch pass in the new pass managerChandler Carruth2017-05-261-4/+1
| | | | | | | | | (where it is the only realistic option). This passes the LLVM test suite for me, but I'm clearly still hammering on this. llvm-svn: 303952
OpenPOWER on IntegriCloud