summaryrefslogtreecommitdiff
path: root/llvm/lib/Transforms/Utils/LoopSimplify.cpp
AgeCommit message (Collapse)Author
2025-01-24[NFC][DebugInfo] Use iterator-flavour getFirstNonPHI at many call-sites ↵Jeremy Morse
(#123737) As part of the "RemoveDIs" project, BasicBlock::iterator now carries a debug-info bit that's needed when getFirstNonPHI and similar feed into instruction insertion positions. Call-sites where that's necessary were updated a year ago; but to ensure some type safety however, we'd like to have all calls to getFirstNonPHI use the iterator-returning version. This patch changes a bunch of call-sites calling getFirstNonPHI to use getFirstNonPHIIt, which returns an iterator. All these call sites are where it's obviously safe to fetch the iterator then dereference it. A follow-up patch will contain less-obviously-safe changes. We'll eventually deprecate and remove the instruction-pointer getFirstNonPHI, but not before adding concise documentation of what considerations are needed (very few). --------- Co-authored-by: Stephen Tozer <Melamoto@gmail.com>
2025-01-09[PM] Remove is_analysis label for LoopSimplify (#121433)Akshat Oke
This reverts part of the changes in #118779
2024-12-06[CodeGen][PM] Initialize analyses with isAnalysis=true (#118779)Akshat Oke
Analyses should be marked as analyses. Otherwise they are prone to get ignored by the legacy analysis cache mechanism and get scheduled redundantly.
2024-10-01LoopSimplify: strip dependency on DA (NFC) (#107379)Ramkumar Ramachandra
Since no passes compute DependenceAnalysis via the PassManager, there is no value in preserving it here. Hence, strip the unnecessary dependency on DependenceAnalysis.
2024-08-04[llvm] Use llvm::is_contained (NFC) (#101855)Kazu Hirata
2024-08-02[NFC] Lowercase the first letter of functions defined in SimplifyCFG.cppShengchen Kan
2024-07-02[Transforms] Use range-based for loops (NFC) (#97195)Kazu Hirata
2024-06-27[IR] Add getDataLayout() helpers to BasicBlock and Instruction (#96902)Nikita Popov
This is a helper to avoid writing `getModule()->getDataLayout()`. I regularly try to use this method only to remember it doesn't exist... `getModule()->getDataLayout()` is also a common (the most common?) reason why code has to include the Module.h header.
2024-03-04[RemoveDIs] Reapply 3fda50d3915, insert instructions using iteratorsJeremy Morse
I'd reverted this in 6c7805d5d1 after a bad stage. Original commit messsage follows: [NFC][RemoveDIs] Bulk update utilities to insert with iterators As part of the RemoveDIs project we need LLVM to insert instructions using iterators wherever possible, so that the iterators can carry a bit of debug-info. This commit implements some of that by updating the contents of llvm/lib/Transforms/Utils to always use iterator-versions of instruction constructors. There are two general flavours of update: * Almost all call-sites just call getIterator on an instruction * Several make use of an existing iterator (scenarios where the code is actually significant for debug-info) The underlying logic is that any call to getFirstInsertionPt or similar APIs that identify the start of a block need to have that iterator passed directly to the insertion function, without being converted to a bare Instruction pointer along the way. I've also switched DemotePHIToStack to take an optional iterator: it needs to take an iterator, and having a no-insert-location behaviour appears to be important. The constructors for ICmpInst and FCmpInst have been updated too. They're the only instructions that take block _references_ rather than pointers for certain calls, and a future patch is going to make use of default-null block insertion locations. All of this should be NFC.
2024-02-29Revert "[NFC][RemoveDIs] Bulk update utilities to insert with iterators"Jeremy Morse
This reverts commit 3fda50d3915b2163a54a37b602be7783a89dd808. Apparently I've missed a hunk while staging this; will back out for now. Picked up here: https://lab.llvm.org/buildbot/#/builders/139/builds/60429/steps/6/logs/stdio
2024-02-29[NFC][RemoveDIs] Bulk update utilities to insert with iteratorsJeremy Morse
As part of the RemoveDIs project we need LLVM to insert instructions using iterators wherever possible, so that the iterators can carry a bit of debug-info. This commit implements some of that by updating the contents of llvm/lib/Transforms/Utils to always use iterator-versions of instruction constructors. There are two general flavours of update: * Almost all call-sites just call getIterator on an instruction * Several make use of an existing iterator (scenarios where the code is actually significant for debug-info) The underlying logic is that any call to getFirstInsertionPt or similar APIs that identify the start of a block need to have that iterator passed directly to the insertion function, without being converted to a bare Instruction pointer along the way. I've also switched DemotePHIToStack to take an optional iterator: it needs to take an iterator, and having a no-insert-location behaviour appears to be important. The constructors for ICmpInst and FCmpInst have been updated too. They're the only instructions that take block _references_ rather than pointers for certain calls, and a future patch is going to make use of default-null block insertion locations. All of this should be NFC.
2023-08-17[IR] Add PHINode::removeIncomingValueIf() (NFC)Nikita Popov
Add an API that allows removing multiple incoming phi values based on a predicate callback, as suggested on D157621. This makes sure that the removal is linear time rather than quadratic, and avoids subtleties around iterator invalidation. I have replaced some of the more straightforward users with the new API, though there's a couple more places that should be able to use it. Differential Revision: https://reviews.llvm.org/D158064
2023-06-05Revert "[LCSSA] Remove unused ScalarEvolution argument (NFC)"Nikita Popov
This reverts commit 5362a0d859d8e96b3f7c0437b7866e17a818a4f7. In preparation for reverting a dependent revision.
2023-05-17[Utils] Use LLVMContext::MD_loop (NFC)Kazu Hirata
2023-05-05[LoopSimplify] Reduce amount of redundant SCEV invalidation (NFCI)Nikita Popov
We are simplifying the loop and all its children. Each time, we invalidate the top-most loop. The top-most loop is going to be the same every time. The cost of SCEV invalidation is largely independent from how data about the loop is actually cached, so we should avoid redundant invalidations.
2023-05-02[LCSSA] Remove unused ScalarEvolution argument (NFC)Nikita Popov
After D149435, LCSSA formation no longer needs access to ScalarEvolution, so remove the argument from the utilities.
2022-12-14[NFC] Cleanup: Replace Function::getBasicBlockList().splice() with ↵Vasileios Porpodas
Function::splice() This is part of a series of patches that aim at making Function::getBasicBlockList() private. Differential Revision: https://reviews.llvm.org/D139984
2022-11-23[NFC] Replaced BB->getInstList().{erase(),pop_front(),pop_back()} with ↵Vasileios Porpodas
eraseFromParent(). Differential Revision: https://reviews.llvm.org/D138617
2022-10-25Revert "reland e5581df60a35 [SimplifyCFG] accumulate bonus insts cost"Yaxun (Sam) Liu
This reverts commit bd7949bcd86633bd4203b2ba6f891aea00fce4d1. Revert this patch since reviwers have different opinions regarding the approach in post-commit review. Will open RFC for further discussion. Differential Revision: https://reviews.llvm.org/D132408
2022-10-24reland e5581df60a35 [SimplifyCFG] accumulate bonus insts costYaxun (Sam) Liu
Fixed compile time increase due to always constructing LocalCostTracker. Now only construct LocalCostTracker when needed.
2022-10-14[Loop] Move block and loop dispo invalidation to makeLoopInvariant.Florian Hahn
makeLoopInvariant may recursively move its operands to make them invariant, before moving the passed in instruction. Those recursively moved instructions are currently missed when invalidating block and loop dispositions. To address this, move the invalidation code to Loop::makeLoopInvariant. Fixes #58314. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D135909
2022-10-07Recommit "[SCEV] Support clearing Block/LoopDispositions for a single value."Florian Hahn
This reverts commit 92f698f01fa0bb8967233a6391ada2d51849fa68. The updated version of the patch includes handling for non-SCEVable types. A test case has been added in ec86e9a99bca802.
2022-10-07Revert "[SCEV] Support clearing Block/LoopDispositions for a single value."Florian Hahn
This reverts commit 9e931439ddb9b6b8f655940b9d8ed6db50c2a7e2. This commit causes a crash when TSan, e.g. with https://lab.llvm.org/buildbot/#/builders/70/builds/28309/steps/10/logs/stdio Reverting while I extract a reproducer and submit a fix.
2022-10-07[SCEV] Support clearing Block/LoopDispositions for a single value.Florian Hahn
Extend forgetBlockAndLoopDisposition to allow clearing information for a single value. This can be useful when only a single value is changed, e.g. because the instruction is moved. We also need to clear the cached values for all SCEV users, because they may depend on the starting value's disposition. Reviewed By: nikic Differential Revision: https://reviews.llvm.org/D134614
2022-09-19Revert "[SimplifyCFG] accumulate bonus insts cost"Nikita Popov
This reverts commit e5581df60a35fffb0c69589777e4e126c849405f. This causes major compile-time regressions, about 2-3% end-to-end on CTMark.
2022-09-19[SCEV][NFC] Remove unused parameter from forgetLoopDispositionsMax Kazantsev
Let's be honest about it, we don't drop loop dispositions for particular loops. Remove the parameter that misleadingly makes it apparent that we do.
2022-09-18[SimplifyCFG] accumulate bonus insts costYaxun (Sam) Liu
SimplifyCFG folds bool foo() { if (cond1) return false; if (cond2) return false; return true; } as bool foo() { if (cond1 | cond2) return false return true; } 'cond2' is called 'bonus insts' in branch folding since they introduce overhead since the original CFG could do early exit but the folded CFG always executes them. SimplifyCFG calculates the costs of 'bonus insts' of a folding a BB into its predecessor BB which shares the destination. If it is below bonus-inst-threshold, SimplifyCFG will fold that BB into its predecessor and cond2 will always be executed. When SimplifyCFG calculates the cost of 'bonus insts', it only consider 'bonus' insts in the current BB to be considered for folding. This causes issue for unrolled loops which share destinations, e.g. bool foo(int *a) { for (int i = 0; i < 32; i++) if (a[i] > 0) return false; return true; } After unrolling, it becomes bool foo(int *a) { if(a[0]>0) return false if(a[1]>0) return false; //... if(a[31]>0) return false; return true; } SimplifyCFG will merge each BB with its predecessor BB, and ends up with 32 'bonus insts' which are always executed, which is much slower than the original CFG. The root cause is that SimplifyCFG does not consider the accumulated cost of 'bonus insts' which are folded from different BB's. This patch fixes that by introducing a ValueMap to track costs of 'bonus insts' coming from different BB's into the same BB, and cuts off if the accumulated cost exceeds a threshold. Reviewed by: Artem Belevich, Florian Hahn, Nikita Popov, Matt Arsenault Differential Revision: https://reviews.llvm.org/D132408
2022-08-27[Transform] Use range-based for loops (NFC)Kazu Hirata
2022-08-27[Transforms] Qualify auto in range-based for loops (NFC)Kazu Hirata
Identified with readability-qualified-auto.
2022-07-18[IR] Don't treat callbr as indirect terminatorNikita Popov
Callbr is no longer an indirect terminator in the sense that is relevant here (that it's successors cannot be updated). The primary effect of this change is that callbr no longer prevents formation of loop simplify form. I decided to drop the isIndirectTerminator() method entirely and replace it with isa<IndirectBrInst>() checks. I assume this method was added to abstract over indirectbr and callbr, but it never really caught on, and there is nothing left to abstract anymore at this point. Differential Revision: https://reviews.llvm.org/D129849
2022-06-09[NFC] format InstructionSimplify & lowerCaseFunctionNamesSimon Moll
Clang-format InstructionSimplify and convert all "FunctionName"s to "functionName". This patch does touch a lot of files but gets done with the cleanup of InstructionSimplify in one commit. This is the alternative to the less invasive clang-format only patch: D126783 Reviewed By: spatel, rengolin Differential Revision: https://reviews.llvm.org/D126889
2022-03-01Cleanup includes: TransformsUtilsserge-sans-paille
Estimation on the impact on preprocessor output: before: 1065307662 after: 1064800684 Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup Differential Revision: https://reviews.llvm.org/D120741
2021-11-19[llvm] Use range-based for loops (NFC)Kazu Hirata
2021-08-16[MemorySSA] Remove -enable-mssa-loop-dependency optionNikita Popov
This option has been enabled by default for quite a while now. The practical impact of removing the option is that MSSA use cannot be disabled in default pipelines (both LPM and NPM) and in manual LPM invocations. NPM can still choose to enable/disable MSSA using loop vs loop-mssa. The next step will be to require MSSA for LICM and drop the AST-based implementation entirely. Differential Revision: https://reviews.llvm.org/D108075
2021-07-26[Local] Do not introduce a new `llvm.trap` before `unreachable`Johannes Doerfert
This is the second attempt to remove the `llvm.trap` insertion after https://reviews.llvm.org/rGe14e7bc4b889dfaffb7180d176a03311df2d4ae6 reverted the first one. It is not clear what the exact issue was back then and it might already be gone by now, it has been >5 years after all. Replaces D106299. Differential Revision: https://reviews.llvm.org/D106308
2021-05-18[NewPM] Don't mark AA analyses as preservedArthur Eubanks
Currently all AA analyses marked as preserved are stateless, not taking into account their dependent analyses. So there's no need to mark them as preserved, they won't be invalidated unless their analyses are. SCEVAAResults was the one exception to this, it was treated like a typical analysis result. Make it like the others and don't invalidate unless SCEV is invalidated. Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D102032
2021-02-07[Transforms/Utils] Use range-based for loops (NFC)Kazu Hirata
2021-01-20[Transforms] Use llvm::append_range (NFC)Kazu Hirata
2020-12-20[SimplifyCFG] Teach FoldBranchToCommonDest() to preserve DomTree, part 1Roman Lebedev
... for conditional branch case
2020-11-16[Transforms] Use pred_empty (NFC)Kazu Hirata
2020-10-30[NFC][LoopSimplify] modernize for loops over LoopInfoPedro Tammela
This patch modifies two for loops to use the range based syntax. Since they are equivalent, this patch is tagged NFC. Differential Revision: https://reviews.llvm.org/D90069
2020-07-20[LoopSimplify] Use SmallPtrSet and range for loops more. NFCI.Benjamin Kramer
2020-07-06DomTree: Remove getChildren() accessorNicolai Hähnle
Summary: Avoid exposing details about how children are stored. This will enable subsequent type-erasure changes. New methods are introduced to cover common access patterns. Change-Id: Idb5f4b1b9c84e4cc71ddb39bb52a388682f5674f Reviewers: arsenm, RKSimon, mehdi_amini, courbet Subscribers: qcolombet, sdardis, wdng, hiraditya, jrtc27, zzheng, atanasyan, asbirlea, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D83083
2020-06-05Correctly report modified status for LoopSimplifyserge-sans-paille
Differential Revision: https://reviews.llvm.org/D81235
2020-05-19[LoopSimplify] don't separate nested loops with convergent callsSameer Sahasrabuddhe
Summary: When a loop has multiple backedges, loop simplification attempts to separate them out into nested loops. This results in incorrect control flow in the presence of some functions like a GPU barrier. This change skips the transformation when such "convergent" function calls are present in the loop body. Reviewed By: nhaehnle Differential Revision: https://reviews.llvm.org/D80078
2019-11-13Sink all InitializePasses.h includesReid Kleckner
This file lists every pass in LLVM, and is included by Pass.h, which is very popular. Every time we add, remove, or rename a pass in LLVM, it caused lots of recompilation. I found this fact by looking at this table, which is sorted by the number of times a file was changed over the last 100,000 git commits multiplied by the number of object files that depend on it in the current checkout: recompiles touches affected_files header 342380 95 3604 llvm/include/llvm/ADT/STLExtras.h 314730 234 1345 llvm/include/llvm/InitializePasses.h 307036 118 2602 llvm/include/llvm/ADT/APInt.h 213049 59 3611 llvm/include/llvm/Support/MathExtras.h 170422 47 3626 llvm/include/llvm/Support/Compiler.h 162225 45 3605 llvm/include/llvm/ADT/Optional.h 158319 63 2513 llvm/include/llvm/ADT/Triple.h 140322 39 3598 llvm/include/llvm/ADT/StringRef.h 137647 59 2333 llvm/include/llvm/Support/Error.h 131619 73 1803 llvm/include/llvm/Support/FileSystem.h Before this change, touching InitializePasses.h would cause 1345 files to recompile. After this change, touching it only causes 550 compiles in an incremental rebuild. Reviewers: bkramer, asbirlea, bollu, jdoerfert Differential Revision: https://reviews.llvm.org/D70211
2019-08-15[llvm] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere
Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. llvm-svn: 369013
2019-08-01[MemorySSA] Set LoopSimplify to preserve MemorySSA in the NPM, if analysis ↵Alina Sbirlea
exists. Summary: LoopSimplify is preserved in the legacy pass manager, but not in the new pass manager. Update LoopSimplify to preserve MemorySSA conditionally when the analysis is available (same behavior as the legacy pass manager). Reviewers: chandlerc Subscribers: mehdi_amini, jlebar, Prazek, george.burgess.iv, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D65418 llvm-svn: 367594
2019-07-12[MemorySSA] Use SetVector to avoid nondeterminism.Alina Sbirlea
Summary: Use a SetVector for DeadBlockSet. Resolves PR42574. Reviewers: george.burgess.iv, uabelho, dblaikie Subscribers: jlebar, Prazek, mgrang, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D64601 llvm-svn: 365970
2019-05-14[MemorySSA] LoopSimplify preserves MemorySSA only when flag is flipped.Alina Sbirlea
LoopSimplify can preserve MemorySSA after r360270. But the MemorySSA analysis is retrieved and preserved only when the EnableMSSALoopDependency is set to true. Use the same conditional to mark the pass as preserved, otherwise subsequent passes will get an invalid analysis. Resolves PR41853. llvm-svn: 360697