summaryrefslogtreecommitdiffstats
path: root/llvm/test/Other/loop-pm-invalidation.ll
Commit message (Collapse)AuthorAgeFilesLines
* [PM] pass -debug-pass-manager flag into FunctionToLoopPassAdaptor's ↵Fedor Sergeev2017-12-291-0/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Do not call Loop::getName on possibly dead loopsSanjoy Das2017-10-041-8/+8
| | | | | | This fixes PR34832. llvm-svn: 314938
* [PM] Relax the patterns used in the new test I added because someChandler Carruth2017-02-101-20/+20
| | | | | | compilers don't print the typedef name. llvm-svn: 294729
* [PM] Fix a bug in the new loop PM when handling functions with no loops.Chandler Carruth2017-02-101-0/+277
Without any loops, we don't even bother to build the standard analyses used by loop passes. Without these, we can't run loop analyses or invalidate them properly. Unfortunately, we did these things in the wrong order which would allow a loop analysis manager's proxy to be built but then not have the standard analyses built. When we went to do the invalidation in the proxy thing would fall apart. In the test case provided, it would actually crash. The fix is to carefully check for loops first, and to in fact build the standard analyses before building the proxy. This allows it to correctly trigger invalidation for those standard analyses. An alternative might seem to be to look at whether there are any loops when doing invalidation, but this doesn't work when during the loop pipeline run we delete the last loop. I've even included that as a test case. It is both simpler and more robust to defer building the proxy until there are definitely the standard set of analyses and indeed loops. This bug was uncovered by enabling GlobalsAA in the pipeline. llvm-svn: 294728
OpenPOWER on IntegriCloud