summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Passes/PassBuilder.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* 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-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | 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
* [PM] Teach the PGO instrumentation pasess to run GlobalDCE beforeChandler Carruth2017-05-251-0/+5
| | | | | | | | | | | | | | | | | | | | | instrumenting code. This is important in the new pass manager. The old pass manager's inliner has a small DCE routine embedded within it. The new pass manager relies on the actual GlobalDCE pass for this. Without this patch, instrumentation profiling with the new PM results in massive code bloat in the object files because the instrumentation itself ends up preventing DCE from working to remove the code. We should probably change the instrumentation (and/or DCE) so that we can eliminate dead code even if instrumented, but we shouldn't even spend the time generating instrumentation for that code so this still seems like a good patch. Differential Revision: https://reviews.llvm.org/D33535 llvm-svn: 303845
* [NewPM] Fix an innocent but silly typo. Reported by Craig Topper.Davide Italiano2017-05-221-1/+1
| | | | llvm-svn: 303587
* [NewPM] Add a temporary cl::opt() to test NewGVN.Davide Italiano2017-05-221-2/+13
| | | | llvm-svn: 303586
* [PartialInlining] Add internal options to enable partial inlining in pass ↵Xinliang David Li2017-05-221-0/+9
| | | | | | | | | | | pipeline (off by default) 1. Legacy: -mllvm -enable-partial-inlining 2. New: -mllvm -enable-npm-partial-inlining -fexperimental-new-pass-manager Differential Revision: http://reviews.llvm.org/D33382 llvm-svn: 303567
* [PM] Add ProfileSummaryAnalysis as a required pass in the new pipeline.Easwaran Raman2017-05-041-0/+4
| | | | | | Differential revision: https://reviews.llvm.org/D32768 llvm-svn: 302170
* [PM/LoopUnswitch] Introduce a new, simpler loop unswitch pass.Chandler Carruth2017-04-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, this pass only focuses on *trivial* loop unswitching. At that reduced problem it remains significantly better than the current loop unswitch: - Old pass is worse than cubic complexity. New pass is (I think) linear. - New pass is much simpler in its design by focusing on full unswitching. (See below for details on this). - New pass doesn't carry state for thresholds between pass iterations. - New pass doesn't carry state for correctness (both miscompile and infloop) between pass iterations. - New pass produces substantially better code after unswitching. - New pass can handle more trivial unswitch cases. - New pass doesn't recompute the dominator tree for the entire function and instead incrementally updates it. I've ported all of the trivial unswitching test cases from the old pass to the new one to make sure that major functionality isn't lost in the process. For several of the test cases I've worked to improve the precision and rigor of the CHECKs, but for many I've just updated them to handle the new IR produced. My initial motivation was the fact that the old pass carried state in very unreliable ways between pass iterations, and these mechansims were incompatible with the new pass manager. However, I discovered many more improvements to make along the way. This pass makes two very significant assumptions that enable most of these improvements: 1) Focus on *full* unswitching -- that is, completely removing whatever control flow construct is being unswitched from the loop. In the case of trivial unswitching, this means removing the trivial (exiting) edge. In non-trivial unswitching, this means removing the branch or switch itself. This is in opposition to *partial* unswitching where some part of the unswitched control flow remains in the loop. Partial unswitching only really applies to switches and to folded branches. These are very similar to full unrolling and partial unrolling. The full form is an effective canonicalization, the partial form needs a complex cost model, cannot be iterated, isn't canonicalizing, and should be a separate pass that runs very late (much like unrolling). 2) Leverage LLVM's Loop machinery to the fullest. The original unswitch dates from a time when a great deal of LLVM's loop infrastructure was missing, ineffective, and/or unreliable. As a consequence, a lot of complexity was added which we no longer need. With these two overarching principles, I think we can build a fast and effective unswitcher that fits in well in the new PM and in the canonicalization pipeline. Some of the remaining functionality around partial unswitching may not be relevant today (not many test cases or benchmarks I can find) but if they are I'd like to add support for them as a separate layer that runs very late in the pipeline. Purely to make reviewing and introducing this code more manageable, I've split this into first a trivial-unswitch-only pass and in the next patch I'll add support for full non-trivial unswitching against a *fixed* threshold, exactly like full unrolling. I even plan to re-use the unrolling thresholds, as these are incredibly similar cost tradeoffs: we're cloning a loop body in order to end up with simplified control flow. We should only do that when the total growth is reasonably small. One of the biggest changes with this pass compared to the previous one is that previously, each individual trivial exiting edge from a switch was unswitched separately as a branch. Now, we unswitch the entire switch at once, with cases going to the various destinations. This lets us unswitch multiple exiting edges in a single operation and also avoids numerous extremely bad behaviors, where we would introduce 1000s of branches to test for thousands of possible values, all of which would take the exact same exit path bypassing the loop. Now we will use a switch with 1000s of cases that can be efficiently lowered into a jumptable. This avoids relying on somehow forming a switch out of the branches or getting horrible code if that fails for any reason. Another significant change is that this pass actively updates the CFG based on unswitching. For trivial unswitching, this is actually very easy because of the definition of loop simplified form. Doing this makes the code coming out of loop unswitch dramatically more friendly. We still should run loop-simplifycfg (at the least) after this to clean up, but it will have to do a lot less work. Finally, this pass makes much fewer attempts to simplify instructions based on the unswitch. Something like loop-instsimplify, instcombine, or GVN can be used to do increasingly powerful simplifications based on the now dominating predicate. The old simplifications are things that something like loop-instsimplify should get today or a very, very basic loop-instcombine could get. Keeping that logic separate is a big simplifying technique. Most of the code in this pass that isn't in the old one has to do with achieving specific goals: - Updating the dominator tree as we go - Unswitching all cases in a switch in a single step. I think it is still shorter than just the trivial unswitching code in the old pass despite having this functionality. Differential Revision: https://reviews.llvm.org/D32409 llvm-svn: 301576
* Disable GVN Hoist due to still more bugs being found in it. There isChandler Carruth2017-04-271-1/+6
| | | | | | | | | | also a discussion about exactly what we should do prior to re-enabling it. The current bug is http://llvm.org/PR32821 and the discussion about this is in the review thread for r300200. llvm-svn: 301505
* Simplify the CFG after loop pass cleanup.Filipe Cabecinhas2017-04-261-0/+4
| | | | | | | | | | | | | | | | Summary: Otherwise we might end up with some empty basic blocks or single-entry-single-exit basic blocks. This fixes PR32085 Reviewers: chandlerc, danielcdh Subscribers: mehdi_amini, RKSimon, llvm-commits Differential Revision: https://reviews.llvm.org/D30468 llvm-svn: 301395
* MemorySSA: Move to Analysis, from Transforms/Utils. It's used asDaniel Berlin2017-04-111-1/+1
| | | | | | | | Analysis, it has Analysis passes, and once NewGVN is made an Analysis, this removes the cross dependency from Analysis to Transform/Utils. NFC. llvm-svn: 299980
* Add call branch annotation for ICP promoted direct call in SamplePGO mode.Dehao Chen2017-02-231-3/+5
| | | | | | | | | | | | | | Summary: SamplePGO uses branch_weight annotation to represent callsite hotness. When ICP promotes an indirect call to direct call, we need to make sure the direct call is annotated with branch_weight in SamplePGO mode, so that downstream function inliner can use hot callsite heuristic. Reviewers: davidxl, eraman, xur Reviewed By: davidxl, xur Subscribers: mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D30282 llvm-svn: 296028
* Increases full-unroll threshold.Dehao Chen2017-02-181-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The default threshold for fully unroll is too conservative. This patch doubles the full-unroll threshold This change will affect the following speccpu2006 benchmarks (performance numbers were collected from Intel Sandybridge): Performance: 403 0.11% 433 0.51% 445 0.48% 447 3.50% 453 1.49% 464 0.75% Code size: 403 0.56% 433 0.96% 445 2.16% 447 2.96% 453 0.94% 464 8.02% The compiler time overhead is similar with code size. Reviewers: davidxl, mkuper, mzolotukhin, hfinkel, chandlerc Reviewed By: hfinkel, chandlerc Subscribers: mehdi_amini, zzheng, efriedma, haicheng, hfinkel, llvm-commits Differential Revision: https://reviews.llvm.org/D28368 llvm-svn: 295538
* [PM] Hook up the instrumented PGO machinery in the new PM.Davide Italiano2017-02-131-0/+60
| | | | | | Differential Revision: https://reviews.llvm.org/D29308 llvm-svn: 294955
* [PM] Add devirtualization-based iteration utility into the new PM'sChandler Carruth2017-02-121-1/+10
| | | | | | | | | | | default pipeline. A clang with this patch built with ASan and asserts can build all of the test-suite as well, so it seems to not uncover any latent problems. Differential Revision: https://reviews.llvm.org/D29853 llvm-svn: 294888
* [PM] Enable GlobalsAA in the new PM's pipeline by default.Chandler Carruth2017-02-121-14/+6
| | | | | | | | | | All the invalidation issues and bugs in this seem to be fixed, it has survived a full build of the test suite plus SPEC with asserts and ASan enabled on the Clang binary used. Differential Revision: https://reviews.llvm.org/D29815 llvm-svn: 294887
* [PM] Add Argument Promotion to the pass pipeline.Chandler Carruth2017-02-091-0/+9
| | | | | | | | | | | This needs explicit requires of the optimization remark emission before loop pass pipelines containing LICM as we no longer get it from the inliner -- Argument Promotion may invalidate it. Technically the inliner could also have broken this, but it never came up in testing. Differential Revision: https://reviews.llvm.org/D29595 llvm-svn: 294670
* [PM] Port ArgumentPromotion to the new pass manager.Chandler Carruth2017-02-091-0/+1
| | | | | | | | | | | | | | | Now that the call graph supports efficient replacement of a function and spurious reference edges, we can port ArgumentPromotion to the new pass manager very easily. The old PM-specific bits are sunk into callbacks that the new PM simply doesn't use. Unlike the old PM, the new PM simply does argument promotion and afterward does the update to LCG reflecting the promoted function. Differential Revision: https://reviews.llvm.org/D29580 llvm-svn: 294667
* Rename LowerTypeTestsSummaryAction to PassSummaryAction. NFCI.Peter Collingbourne2017-02-091-2/+2
| | | | | | | | | I intend to use the same type with the same semantics in the WholeProgramDevirt pass. Differential Revision: https://reviews.llvm.org/D29746 llvm-svn: 294629
* Add PredicateInfo utility and printing passDaniel Berlin2017-02-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds a utility to build extended SSA (see "ABCD: eliminating array bounds checks on demand"), and an intrinsic to support it. This is then used to get functionality equivalent to propagateEquality in GVN, in NewGVN (without having to replace instructions as we go). It would work similarly in SCCP or other passes. This has been talked about a few times, so i built a real implementation and tried to productionize it. Copies are inserted for operands used in assumes and conditional branches that are based on comparisons (see below for more) Every use affected by the predicate is renamed to the appropriate intrinsic result. E.g. %cmp = icmp eq i32 %x, 50 br i1 %cmp, label %true, label %false true: ret i32 %x false: ret i32 1 will become %cmp = icmp eq i32, %x, 50 br i1 %cmp, label %true, label %false true: ; Has predicate info ; branch predicate info { TrueEdge: 1 Comparison: %cmp = icmp eq i32 %x, 50 } %x.0 = call @llvm.ssa_copy.i32(i32 %x) ret i32 %x.0 false: ret i23 1 (you can use -print-predicateinfo to get an annotated-with-predicateinfo dump) This enables us to easily determine what operations are affected by a given predicate, and how operations affected by a chain of predicates. Reviewers: davide, sanjoy Subscribers: mgorny, llvm-commits, Prazek Differential Revision: https://reviews.llvm.org/D29519 Update for review comments Fix a bug Nuno noticed where we are giving information about and/or on edges where the info is not useful and easy to use wrong Update for review comments llvm-svn: 294351
* [PM] Port LoopLoadElimination to the new pass manager and wire it intoChandler Carruth2017-01-271-1/+4
| | | | | | | | | | | the main pipeline. This is a very straight forward port. Nothing weird or surprising. This brings the number of missing passes from the new PM's pipeline down to three. llvm-svn: 293249
* [PM] Flesh out almost all of the late loop passes.Chandler Carruth2017-01-271-9/+37
| | | | | | | | | | | | | | | | | | | | | | | | | With this the per-module pass pipeline is *extremely* close to the legacy PM. The missing pieces are: - PruneEH (or some equivalent) - ArgumentPromotion - LoopLoadElimination - LoopUnswitch I'm going to work through those in essentially that order but this seems like a worthwhile incremental step toward the end state. One difference in what I have here from the legacy PM is that I've consolidated some of the per-function passes at the very end of the pipeline into the main optimization function pipeline. The intervening passes are *really* uninteresting and so this seems very likely to have any effect other than minor improvement to locality. Note that there are still some failures in the test suite, but the compiler doesn't crash or assert. Differential Revision: https://reviews.llvm.org/D29114 llvm-svn: 293241
* [PM] Enable the main loop pass pipelines with everything butChandler Carruth2017-01-261-12/+6
| | | | | | | | | | | | | | | | loop-unswitch in the main pipelines for the new PM. All of these now work, and Clang built using this pipeline can build the test suite and SPEC without hitting any asserts of ASan failures. There are still some bugs hiding though -- 7 tests regress with the new PM. I'm going to be investigating these, but it seems worthwhile to at least get the pipelines in place so that others can play with them, and they aren't completely broken. Differential Revision: https://reviews.llvm.org/D29113 llvm-svn: 293225
* [Guards] Introduce loop-predication passArtur Pilipenko2017-01-251-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch introduces guard based loop predication optimization. The new LoopPredication pass tries to convert loop variant range checks to loop invariant by widening checks across loop iterations. For example, it will convert for (i = 0; i < n; i++) { guard(i < len); ... } to for (i = 0; i < n; i++) { guard(n - 1 < len); ... } After this transformation the condition of the guard is loop invariant, so loop-unswitch can later unswitch the loop by this condition which basically predicates the loop by the widened condition: if (n - 1 < len) for (i = 0; i < n; i++) { ... } else deoptimize This patch relies on an NFC change to make ScalarEvolution::isMonotonicPredicate public (revision 293062). Reviewed By: sanjoy Differential Revision: https://reviews.llvm.org/D29034 llvm-svn: 293064
* [PM] Flesh out the new pass manager LTO pipeline.Davide Italiano2017-01-241-5/+158
| | | | | | Differential Revision: https://reviews.llvm.org/D28996 llvm-svn: 292863
* [PM] Port LoopSink to the new pass manager.Chandler Carruth2017-01-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | Like several other loop passes (the vectorizer, etc) this pass doesn't really fit the model of a loop pass. The critical distinction is that it isn't intended to be pipelined together with other loop passes. I plan to add some documentation to the loop pass manager to make this more clear on that side. LoopSink is also different because it doesn't really need a lot of the infrastructure of our loop passes. For example, if there aren't loop invariant instructions causing a preheader to exist, there is no need to form a preheader. It also doesn't need LCSSA because this pass is only involved in sinking invariant instructions from a preheader into the loop, not reasoning about live-outs. This allows some nice simplifications to the pass in the new PM where we can directly walk the loops once without restructuring them. Differential Revision: https://reviews.llvm.org/D28921 llvm-svn: 292589
* [PM] Add LoopVectorize to the default module pipelineMichael Kuperstein2017-01-191-4/+0
| | | | | | | | LV no longer "requires" LCSSA and LoopSimplify, and instead forms them internally as required. So, there's nothing preventing it from being enabled. llvm-svn: 292464
* [PM] Separate the LoopAnalysisManager from the LoopPassManager and moveChandler Carruth2017-01-111-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | the latter to the Transforms library. While the loop PM uses an analysis to form the IR units, the current plan is to have the PM itself establish and enforce both loop simplified form and LCSSA. This would be a layering violation in the analysis library. Fundamentally, the idea behind the loop PM is to *transform* loops in addition to running passes over them, so it really seemed like the most natural place to sink this was into the transforms library. We can't just move *everything* because we also have loop analyses that rely on a subset of the invariants. So this patch splits the the loop infrastructure into the analysis management that has to be part of the analysis library, and the transform-aware pass manager. This also required splitting the loop analyses' printer passes out to the transforms library, which makes sense to me as running these will transform the code into LCSSA in theory. I haven't split the unittest though because testing one component without the other seems nearly intractable. Differential Revision: https://reviews.llvm.org/D28452 llvm-svn: 291662
* [PM] Rewrite the loop pass manager to use a worklist and augmented runChandler Carruth2017-01-111-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | arguments much like the CGSCC pass manager. This is a major redesign following the pattern establish for the CGSCC layer to support updates to the set of loops during the traversal of the loop nest and to support invalidation of analyses. An additional significant burden in the loop PM is that so many passes require access to a large number of function analyses. Manually ensuring these are cached, available, and preserved has been a long-standing burden in LLVM even with the help of the automatic scheduling in the old pass manager. And it made the new pass manager extremely unweildy. With this design, we can package the common analyses up while in a function pass and make them immediately available to all the loop passes. While in some cases this is unnecessary, I think the simplicity afforded is worth it. This does not (yet) address loop simplified form or LCSSA form, but those are the next things on my radar and I have a clear plan for them. While the patch is very large, most of it is either mechanically updating loop passes to the new API or the new testing for the loop PM. The code for it is reasonably compact. I have not yet updated all of the loop passes to correctly leverage the update mechanisms demonstrated in the unittests. I'll do that in follow-up patches along with improved FileCheck tests for those passes that ensure things work in more realistic scenarios. In many cases, there isn't much we can do with these until the loop simplified form and LCSSA form are in place. Differential Revision: https://reviews.llvm.org/D28292 llvm-svn: 291651
* [PM] Introduce a devirtualization iteration layer for the new PM.Chandler Carruth2016-12-281-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is an orthogonal and separated layer instead of being embedded inside the pass manager. While it adds a small amount of complexity, it is fairly minimal and the composability and control seems worth the cost. The logic for this ends up being nicely isolated and targeted. It should be easy to experiment with different iteration strategies wrapped around the CGSCC bottom-up walk using this kind of facility. The mechanism used to track devirtualization is the simplest one I came up with. I think it handles most of the cases the existing iteration machinery handles, but I haven't done a *very* in depth analysis. It does however match the basic intended semantics, and we can tweak or tune its exact behavior incrementally as necessary. One thing that we may want to revisit is freshly building the value handle set on each iteration. While I don't think this will be a significant cost (it is strictly fewer value handles but more churn of value handes than the old call graph), it is conceivable that we'll want a somewhat more clever tracking mechanism. My hope is to layer that on as a follow up patch with data supporting any implementation complexity it adds. This code also provides for a basic count heuristic: if the number of indirect calls decreases and the number of direct calls increases for a given function in the SCC, we assume devirtualization is responsible. This matches the heuristics currently used in the legacy pass manager. Differential Revision: https://reviews.llvm.org/D23114 llvm-svn: 290665
* [PM] Disable the loop vectorizer from the new PM's pipeline as itChandler Carruth2016-12-281-0/+4
| | | | | | | | | | | currenty relies on the old PM's dependency system forming LCSSA. The new PM will require a different design for this, and for now this is causing most of the issues I'm currently seeing in testing. I'd like to get to a testable baseline and then work on re-enabling things one at a time. llvm-svn: 290644
* [PM] Disable more of the loop passes -- LCSSA and LoopSimplify are alsoChandler Carruth2016-12-271-3/+9
| | | | | | | | | | | | | not really wired into the loop pass manager in a way that will let us productively use these passes yet. This lets the new PM get farther in basic testing which is useful for establishing a good baseline of "doesn't explode". There are still plenty of crashers in basic testing though, this just gets rid of some noise that is well understood and not representing a specific or narrow bug. llvm-svn: 290601
OpenPOWER on IntegriCloud