aboutsummaryrefslogtreecommitdiff
path: root/llvm/lib/Analysis/LoopAnalysisManager.cpp
AgeCommit message (Collapse)AuthorFilesLines
2019-08-21[LoopPassManager + MemorySSA] Only enable use of MemorySSA for LPMs known to ↵Alina Sbirlea1-1/+1
preserve it. Summary: Add a flag to the FunctionToLoopAdaptor that allows enabling MemorySSA only for the loop pass managers that are known to preserve it. If an LPM is known to have only loop transforms that *all* preserve MemorySSA, then use MemorySSA if `EnableMSSALoopDependency` is set. If an LPM has loop passes that do not preserve MemorySSA, then the flag passed is `false`, regardless of the value of `EnableMSSALoopDependency`. When using a custom loop pass pipeline via `passes=...`, use keyword `loop` vs `loop-mssa` to use MemorySSA in that LPM. If a loop that does not preserve MemorySSA is added while using the `loop-mssa` keyword, that's an error. Add the new `loop-mssa` keyword to a few tests where a difference occurs when enabling MemorySSA. Reviewers: chandlerc Subscribers: mehdi_amini, Prazek, george.burgess.iv, sanjoy.google, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66376 llvm-svn: 369548
2019-06-11Only passes that preserve MemorySSA must mark it as preserved.Alina Sbirlea1-2/+0
Summary: The method `getLoopPassPreservedAnalyses` should not mark MemorySSA as preserved, because it's being called in a lot of passes that do not preserve MemorySSA. Instead, mark the MemorySSA analysis as preserved by each pass that does preserve it. These changes only affect the new pass mananger. Reviewers: chandlerc Subscribers: mehdi_amini, jlebar, Prazek, george.burgess.iv, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62536 llvm-svn: 363091
2019-04-23[MemorySSA] LCSSA preserves MemorySSA.Alina Sbirlea1-5/+0
Summary: Enabling MemorySSA in the old pass manager leads to MemorySSA being run twice due to the fact that LCSSA and LoopSimplify do not preserve MemorySSA. This is the first step to address that: target LCSSA. LCSSA does not make any changes that invalidate MemorySSA, so it preserves it by design. It must preserve AA as well, for this to hold. After this patch, MemorySSA is still run twice in the old pass manager. Step two follows: target LoopSimplify. Subscribers: mehdi_amini, jlebar, Prazek, llvm-commits, george.burgess.iv, chandlerc Tags: #llvm Differential Revision: https://reviews.llvm.org/D60832 llvm-svn: 359032
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-4/+3
to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2018-09-06[LoopPassManager] MemorySSA should be preserved when enabled.Alina Sbirlea1-2/+2
llvm-svn: 341587
2018-02-28Fixed spelling mistake in comments of LLVM Analysis passesVedant Kumar1-1/+1
Patch by Reshabh Sharma! Differential Revision: https://reviews.llvm.org/D43861 llvm-svn: 326352
2017-11-21Add MemorySSA as loop dependency, disabled by default [NFC].Alina Sbirlea1-3/+15
Summary: First step in adding MemorySSA as dependency for loop pass manager. Adding the dependency under a flag. New pass manager: MSSA pointer in LoopStandardAnalysisResults can be null. Legacy and new pass manager: Use cl::opt EnableMSSALoopDependency. Disabled by default. Reviewers: sanjoy, davide, gberry Subscribers: mehdi_amini, Prazek, llvm-commits Differential Revision: https://reviews.llvm.org/D40274 llvm-svn: 318772
2017-10-04Do not call Loop::getName on possibly dead loopsSanjoy Das1-2/+4
This fixes PR34832. llvm-svn: 314938
2017-09-28Use a BumpPtrAllocator for Loop objectsSanjoy Das1-1/+1
Summary: And now that we no longer have to explicitly free() the Loop instances, we can (with more ease) use the destructor of LoopBase to do what LoopBase::clear() was doing. Reviewers: chandlerc Subscribers: mehdi_amini, mcrosier, llvm-commits Differential Revision: https://reviews.llvm.org/D38201 llvm-svn: 314375
2017-02-07Revert r293017 and fix the actual underlying issue.Chandler Carruth1-1/+2
The patch committed in r293017, as discussed on the list, doesn't really make sense but was causing an actual issue to go away. The issue turns out to be that in one place the extra template arguments were dropped from the OuterAnalysisManagerProxy. This in turn caused the types used in one set of places to access the key to be completely different from the types used in another set of places for both Loop and CGSCC cases where there are extra arguments. I have literally no idea how anything seemed to work with this bug in place. It blows my mind. But it did except for mingw64 in a DLL build. I've added a really handy static assert that helps ensure we don't break this in the future. It immediately diagnoses the issue with a compile failure and a very clear error message. Much better that staring at backtraces on a build bot. =] llvm-svn: 294267
2017-01-25Rewind instantiations of OuterAnalysisManagerProxy in r289317, r291651, and ↵NAKAMURA Takumi1-2/+1
r291662. I found root class should be instantiated for variadic tempate to instantiate static member explicitly. This will fix failures in mingw DLL build. llvm-svn: 293017
2017-01-20[LoopInfo] Add helper methods to compute two useful orderings of theChandler Carruth1-18/+4
loops in a function. These are relatively confusing to talk about and compute correctly so it seems really good to write down their implementation in one place. I've replaced one place we needed this in the loop PM infrastructure and I have another place in a pending patch that wants it. We can't quite use this for the core loop PM walk because there we're sometimes working on a sub-forest. I'll add the expected unittests before committing this but wanted to make sure folks were happy with these names / comments. Credit goes to Richard Smith for the idea for naming the order where siblings are in reverse program order but the tree traversal remains preorder. Differential Revision: https://reviews.llvm.org/D28932 llvm-svn: 292569
2017-01-15[PM] The assumption cache is fundamentally designed to be self-updating,Chandler Carruth1-1/+0
mark it as never invalidated in the new PM. The old PM already required this to work, and after a discussion with Hal this seems to really be the only sensible answer. The cache gracefully degrades as the IR is mutated, and most things which do this should already be incrementally updating the cache. This gets rid of a bunch of logic preserving and testing the invalidation of this analysis. llvm-svn: 292039
2017-01-11[PM] Separate the LoopAnalysisManager from the LoopPassManager and moveChandler Carruth1-0/+160
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
generated by cgit v1.1 at 2025-10-09 22:18:27 +0000