summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Passes
Commit message (Collapse)AuthorAgeFilesLines
...
* Revert "Separate the Verifier into an analysis and a transformation pass and"Adrian Prantl2016-05-091-2/+0
| | | | | | This reverts commit 268937 while investigating build bot breakage. llvm-svn: 268939
* Separate the Verifier into an analysis and a transformation pass andAdrian Prantl2016-05-091-0/+2
| | | | | | | | | | | | | | | | | | | | | | allow the transformation to strip invalid debug info. This patch separates the Verifier into an analysis and a transformation pass, with the transformation pass optionally stripping malformed debug info. The problem I'm trying to solve with this sequence of patches is that historically we've done a really bad job at verifying debug info. We want to be able to make the verifier stricter without having to worry about breaking bitcode compatibility with existing producers. For example, we don't necessarily want IR produced by an older version of clang to be rejected by an LTO link just because of malformed debug info, and rather provide an option to strip it. Note that merely outdated (but well-formed) debug info would continue to be auto-upgraded in this scenario. http://reviews.llvm.org/D19988 rdar://problem/25818489 llvm-svn: 268937
* [PM] port IR based PGO prof-gen pass to new pass managerXinliang David Li2016-05-062-0/+2
| | | | llvm-svn: 268710
* [PM] port Branch Frequency Analaysis pass to new PMXinliang David Li2016-05-052-0/+4
| | | | llvm-svn: 268687
* [PM] Port Interprocedural SCCP to the new pass manager.Davide Italiano2016-05-052-0/+2
| | | | llvm-svn: 268684
* [PM] Port Branch Probability Analysis pass to the new pass manager.Xinliang David Li2016-05-052-0/+3
| | | | | | Differential Revision: http://reviews.llvm.org/D19839 llvm-svn: 268601
* [PM] Port EliminateAvailableExternally pass to the new pass manager.Davide Italiano2016-05-052-0/+2
| | | | llvm-svn: 268599
* [PM] Port ConstantMerge to the new pass manager.Davide Italiano2016-05-052-1/+3
| | | | llvm-svn: 268582
* PM: Port LoopRotation to the new loop pass managerJustin Bogner2016-05-032-0/+2
| | | | llvm-svn: 268452
* PM: Port LoopSimplifyCFG to the new pass managerJustin Bogner2016-05-032-0/+2
| | | | llvm-svn: 268446
* [IPO/GlobalDCE] Port to the new pass manager.Davide Italiano2016-05-032-0/+2
| | | | | | Differential Revision: http://reviews.llvm.org/D19782 llvm-svn: 268425
* PM: Port Reassociate to the new pass managerJustin Bogner2016-04-262-0/+2
| | | | llvm-svn: 267631
* PM: Port Internalize to the new pass managerJustin Bogner2016-04-262-0/+2
| | | | llvm-svn: 267596
* PM: Port GlobalOpt to the new pass managerJustin Bogner2016-04-262-0/+2
| | | | llvm-svn: 267499
* PM: Port SinkingPass to the new pass managerJustin Bogner2016-04-222-0/+2
| | | | llvm-svn: 267199
* PM: Port DCE to the new pass managerJustin Bogner2016-04-222-0/+2
| | | | | | | Also add a very basic test, since apparently there aren't any tests for DCE whatsoever to add the new pass version to. llvm-svn: 267196
* Port DemandedBits to the new pass manager.Michael Kuperstein2016-04-182-0/+3
| | | | | | Differential Revision: http://reviews.llvm.org/D18679 llvm-svn: 266699
* Fix shared build of LLVMPasses.Marcin Koscielnicki2016-04-181-1/+1
| | | | | | | It's missing a dependency on Instrumentation (needed for llvm::InstrProfiling::run(llvm::Module&, llvm::AnalysisManager<llvm::Module>&)) llvm-svn: 266656
* Port InstrProfiling pass to the new pass managerXinliang David Li2016-04-182-0/+2
| | | | | | Differential Revision: http://reviews.llvm.org/D18126 llvm-svn: 266637
* [PM] Rename the CRTP mixin base classes for the new pass manager toChandler Carruth2016-03-111-8/+8
| | | | | | | | | | | | | | | | | | | | clarify their purpose. Firstly, call them "...Mixin" types so it is clear that there is no type hierarchy being formed here. Secondly, use the term 'Info' to clarify that they aren't adding any interesting *semantics* to the passes or analyses, just exposing APIs used by the management layer to get information about the pass or analysis. Thanks to Manuel for helping pin down the naming confusion here and come up with effective names to address it. In case you already have some out-of-tree stuff, the following should be roughly what you want to update: perl -pi -e 's/\b(Pass|Analysis)Base\b/\1InfoMixin/g' llvm-svn: 263217
* [PM] Implement the final conclusion as to how the analysis IDs shouldChandler Carruth2016-03-111-4/+25
| | | | | | | | | | | | | | | | | | | | work in the face of the limitations of DLLs and templated static variables. This requires passes that use the AnalysisBase mixin provide a static variable themselves. So as to keep their APIs clean, I've made these private and befriended the CRTP base class (which is the common practice). I've added documentation to AnalysisBase for why this is necessary and at what point we can go back to the much simpler system. This is clearly a better pattern than the extern template as it caught *numerous* places where the template magic hadn't been applied and things were "just working" but would eventually have broken mysteriously. llvm-svn: 263216
* [PM/AA] Teach the AAManager how to handle module analyses in addition toChandler Carruth2016-03-112-0/+14
| | | | | | | function analyses, and use it to wire up globals-aa to the new pass manager. llvm-svn: 263211
* [PM] Port GVN to the new pass manager, wire it up, and teach a couple ofChandler Carruth2016-03-112-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | tests to run GVN in both modes. This is mostly the boring refactoring just like SROA and other complex transformation passes. There is some trickiness in that GVN's ValueNumber class requires hand holding to get to compile cleanly. I'm open to suggestions about a better pattern there, but I tried several before settling on this. I was trying to balance my desire to sink as much implementation detail into the source file as possible without introducing overly many layers of abstraction. Much like with SROA, the design of this system is made somewhat more cumbersome by the need to support both pass managers without duplicating the significant state and logic of the pass. The same compromise is struck here. I've also left a FIXME in a doxygen comment as the GVN pass seems to have pretty woeful documentation within it. I'd like to submit this with the FIXME and let those more deeply familiar backfill the information here now that we have a nice place in an interface to put that kind of documentaiton. Differential Revision: http://reviews.llvm.org/D18019 llvm-svn: 263208
* [CG] Add a new pass manager printer pass for the old call graph andChandler Carruth2016-03-102-0/+3
| | | | | | | | | | | | | | | | | actually finish wiring up the old call graph. There were bugs in the old call graph that hadn't been caught because it wasn't being tested. It wasn't being tested because it wasn't in the pipeline system and we didn't have a printing pass to run in tests. This fixes all of that. As for why I'm still keeping the old call graph alive its so that I can port GlobalsAA to the new pass manager with out forking it to work with the lazy call graph. That's clearly the right eventual design, but it seems pragmatic to defer that until its necessary. The old call graph works just fine for GlobalsAA. llvm-svn: 263104
* [LCG] Spell the printing pass pipeline name for the lazy call graphChandler Carruth2016-03-101-1/+1
| | | | | | | | | | 'lcg' instead of just 'cg'. This makes it consistent with the analysis name of 'lcg'. No functionality changed. llvm-svn: 263103
* [PM] Port memdep to the new pass manager.Chandler Carruth2016-03-102-0/+2
| | | | | | | | | | | | | | | | | | | | | | | This is a fairly straightforward port to the new pass manager with one exception. It removes a very questionable use of releaseMemory() in the old pass to invalidate its caches between runs on a function. I don't think this is really guaranteed to be safe. I've just used the more direct port to the new PM to address this by nuking the results object each time the pass runs. While this could cause some minor malloc traffic increase, I don't expect the compile time performance hit to be noticable, and it makes the correctness and other aspects of the pass much easier to reason about. In some cases, it may make things faster by making the sets and maps smaller with better locality. Indeed, the measurements collected by Bruno (thanks!!!) show mostly compile time improvements. There is sadly very limited testing at this point as there are only two tests of memdep, and both rely on GVN. I'll be porting GVN next and that will exercise this heavily though. Differential Revision: http://reviews.llvm.org/D17962 llvm-svn: 263082
* [PM] Wire up optimization levels and default pipeline construction APIsChandler Carruth2016-02-281-2/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | in the PassBuilder. These are really just stubs for now, but they give a nice API surface that Clang or other tools can start learning about and enabling for experimentation. I've also wired up parsing various synthetic module pass names to generate these set pipelines. This allows the pipelines to be combined with other passes and have their order controlled, with clear separation between the *kind* of canned pipeline, and the *level* of optimization to be used within that canned pipeline. The most interesting part of this patch is almost certainly the spec for the different optimization levels. I don't think we can ever have hard and fast rules that would make it easy to determine whether a particular optimization makes sense at a particular level -- it will always be in large part a judgement call. But hopefully this will outline the expected rationale that should be used, and the direction that the pipelines should be taken. Much of this was based on a long llvm-dev discussion I started years ago to try and crystalize the intent behind these pipelines, and now, at long long last I'm returning to the task of actually writing it down somewhere that we can cite and try to be consistent with. Differential Revision: http://reviews.llvm.org/D12826 llvm-svn: 262196
* [PM] Finish removing references to fix MSVC builds. Somehow adding baseChandler Carruth2016-02-261-8/+16
| | | | | | | | | classes changed whether the decltype of these expressions was a reference. I'm somewhat horrified why, and there may need to be a deeper fix on MSVC, but this should at least get the bots a step further. llvm-svn: 262008
* [PM] Speculative patch to try and fix MSVC's compilation.Chandler Carruth2016-02-261-1/+3
| | | | | | No idea why r262004 triggered this, but just trying to fix somehow. llvm-svn: 262006
* [PM] Introduce CRTP mixin base classes to help define passes andChandler Carruth2016-02-261-24/+4
| | | | | | | | | | | | | | | | | analyses in the new pass manager. These just handle really basic stuff: turning a type name into a string statically that is nice to print in logs, and getting a static unique ID for each analysis. Sadly, the format of passes in anonymous namespaces makes using their names in tests really annoying so I've customized the names of the no-op passes to keep tests sane to read. This is the first of a few simplifying refactorings for the new pass manager that should reduce boilerplate and confusion. llvm-svn: 262004
* Introduce RegionInfoAnalysis, which compute Region Tree in the new ↵Hongbin Zheng2016-02-252-0/+4
| | | | | | | | PassManager. NFC Differential Revision: http://reviews.llvm.org/D17571 llvm-svn: 261904
* Introduce DominanceFrontierAnalysis to the new PassManager to compute ↵Hongbin Zheng2016-02-252-0/+3
| | | | | | | | DominanceFrontier. NFC Differential Revision: http://reviews.llvm.org/D17570 llvm-svn: 261903
* Introduce analysis pass to compute PostDominators in the new pass manager. NFCHongbin Zheng2016-02-252-0/+3
| | | | | | Differential Revision: http://reviews.llvm.org/D17537 llvm-svn: 261902
* Revert "Introduce analysis pass to compute PostDominators in the new pass ↵Hongbin Zheng2016-02-252-3/+0
| | | | | | | | manager. NFC" This reverts commit a3e5cc6a51ab5ad88d1760c63284294a4e34c018. llvm-svn: 261891
* Revert "Introduce DominanceFrontierAnalysis to the new PassManager to ↵Hongbin Zheng2016-02-252-3/+0
| | | | | | | | compute DominanceFrontier. NFC" This reverts commit 109c38b2226a87b0be73fa7a0a8c1a81df20aeb2. llvm-svn: 261890
* Revert "Introduce RegionInfoAnalysis, which compute Region Tree in the new ↵Hongbin Zheng2016-02-252-4/+0
| | | | | | | | PassManager. NFC" This reverts commit 8228b4d374edeb4cc0c5fddf6e1ab876918ee126. llvm-svn: 261889
* Introduce RegionInfoAnalysis, which compute Region Tree in the new ↵Hongbin Zheng2016-02-252-0/+4
| | | | | | | | PassManager. NFC Differential Revision: http://reviews.llvm.org/D17571 llvm-svn: 261884
* Introduce DominanceFrontierAnalysis to the new PassManager to compute ↵Hongbin Zheng2016-02-252-0/+3
| | | | | | | | DominanceFrontier. NFC Differential Revision: http://reviews.llvm.org/D17570 llvm-svn: 261883
* Introduce analysis pass to compute PostDominators in the new pass manager. NFCHongbin Zheng2016-02-252-0/+3
| | | | | | Differential Revision: http://reviews.llvm.org/D17537 llvm-svn: 261882
* PM: Implement a basic loop pass managerJustin Bogner2016-02-252-2/+138
| | | | | | | | | | | This creates the new-style LoopPassManager and wires it up with dummy and print passes. This version doesn't support modifying the loop nest at all. It will be far easier to discuss and evaluate the approaches to that with this in place so that the boilerplate is out of the way. llvm-svn: 261831
* [PM/AA] Wire up TBAA to the new pass manager's registry and test it.Chandler Carruth2016-02-202-0/+2
| | | | llvm-svn: 261411
* [PM/AA] Wire up the scoped-no-alias AA to the new pass manager'sChandler Carruth2016-02-202-0/+2
| | | | | | registry and test it. llvm-svn: 261410
* [PM/AA] Wire up SCEVAA to the new pass manager's registry and test it.Chandler Carruth2016-02-202-0/+2
| | | | llvm-svn: 261409
* [PM/AA] Wire up CFLAA to the new pass manager fully, and port one of itsChandler Carruth2016-02-202-0/+2
| | | | | | | | | tests over to exercise this code. This uncovered a few missing bits here and there in the analysis, but nothing interesting. llvm-svn: 261404
* [PM/AA] Port alias analysis evaluator to the new pass manager, and useChandler Carruth2016-02-202-0/+2
| | | | | | | | | | | | | | | | it to actually test the new pass manager AA wiring. This patch was extracted from the (somewhat too large) D12357 and rebosed on top of the slightly different design of the new pass manager AA wiring that I just landed. With this we can start testing the AA in a thorough way with the new pass manager. Some minor cleanups to the code in the pass was necessitated here, but otherwise it is a very minimal change. Differential Revision: http://reviews.llvm.org/D17372 llvm-svn: 261403
* [PM] Port the PostOrderFunctionAttrs pass to the new pass manager andChandler Carruth2016-02-182-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | convert one test to use this. This is a particularly significant milestone because it required a working per-function AA framework which can be queried over each function from within a CGSCC transform pass (and additionally a module analysis to be accessible). This is essentially *the* point of the entire pass manager rewrite. A CGSCC transform is able to query for multiple different function's analysis results. It works. The whole thing appears to actually work and accomplish the original goal. While we were able to hack function attrs and basic-aa to "work" in the old pass manager, this port doesn't use any of that, it directly leverages the new fundamental functionality. For this to work, the CGSCC framework also has to support SCC-based behavior analysis, etc. The only part of the CGSCC pass infrastructure not sorted out at this point are the updates in the face of inlining and running function passes that mutate the call graph. The changes are pretty boring and boiler-plate. Most of the work was factored into more focused preperatory patches. But this is what wires it all together. llvm-svn: 261203
* [PM/AA] Teach the new pass manager to use pass-by-lambda for registeringChandler Carruth2016-02-182-4/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | analysis passes, support pre-registering analyses, and use that to implement parsing and pre-registering a custom alias analysis pipeline. With this its possible to configure the particular alias analysis pipeline used by the AAManager from the commandline of opt. I've updated the test to show this effectively in use to build a pipeline including basic-aa as part of it. My big question for reviewers are around the APIs that are used to expose this functionality. Are folks happy with pass-by-lambda to do pass registration? Are folks happy with pre-registering analyses as a way to inject customized instances of an analysis while still using the registry for the general case? Other thoughts of course welcome. The next round of patches will be to add the rest of the alias analyses into the new pass manager and wire them up here so that they can be used from opt. This will require extending the (somewhate limited) functionality of AAManager w.r.t. module passes. Differential Revision: http://reviews.llvm.org/D17259 llvm-svn: 261197
* [PM/AA] Wire BasicAA's new pass manager class up to the pass registry.Chandler Carruth2016-02-132-0/+2
| | | | | | | | This ensures that all of the various pieces are working. The next patch will wire up commandline-driven alias analysis chain building and allow BasicAA to work with the AAManager. llvm-svn: 260838
* [PM/AA] Actually wire the AAManager I built for the new pass managerChandler Carruth2016-02-132-0/+2
| | | | | | | | | | | | into the new pass manager and fix the latent bugs there. This lets everything live together nicely, but it isn't really useful yet. I never finished wiring the AA layer up for the new pass manager, and so subsequent patches will change this to do that wiring and get AA stuff more fully integrated into the new pass manager. Turns out this is necessary even to get functionattrs ported over. =] llvm-svn: 260836
* Remove autoconf supportChris Bieneman2016-01-261-14/+0
| | | | | | | | | | | | | | | | Summary: This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html "I felt a great disturbance in the [build system], as if millions of [makefiles] suddenly cried out in terror and were suddenly silenced. I fear something [amazing] has happened." - Obi Wan Kenobi Reviewers: chandlerc, grosbach, bob.wilson, tstellarAMD, echristo, whitequark Subscribers: chfast, simoncook, emaste, jholewinski, tberghammer, jfb, danalbert, srhines, arsenm, dschuff, jyknight, dsanders, joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D16471 llvm-svn: 258861
OpenPOWER on IntegriCloud