RPCS3/llvm-mirror
1
0
Fork 0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2024-11-25 20:23:11 +01:00
Code Issues Projects Releases Wiki Activity
28d769100d
llvm-mirror/lib/Passes/PassRegistry.def

456 lines
22 KiB
Modula-2
Raw Normal View History

[PM] Add a nice low-tech registry of passes as a boring macro expansion file. This will make it easy to scale up the number of passes supported. Currently, it just supports the function and module transformation passes that were already supported in the opt tool explicitly. llvm-svn: 206737
2014-04-21 10:08:50 +02:00
//===- PassRegistry.def - Registry of passes --------------------*- C++ -*-===//
//
Update the file headers across all of the LLVM projects in the monorepo 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
2019-01-19 09:50:56 +01:00
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
[PM] Add a nice low-tech registry of passes as a boring macro expansion file. This will make it easy to scale up the number of passes supported. Currently, it just supports the function and module transformation passes that were already supported in the opt tool explicitly. llvm-svn: 206737
2014-04-21 10:08:50 +02:00
//
//===----------------------------------------------------------------------===//
//
// This file is used as the registry of passes that are part of the core LLVM
// libraries. This file describes both transformation passes and analyses
// Analyses are registered while transformation passes have names registered
// that can be used when providing a textual pass pipeline.
//
//===----------------------------------------------------------------------===//
// NOTE: NO INCLUDE GUARD DESIRED!
[PM] Wire the analysis passes (such as they are) into the registry, and teach the opt driver to use it rather than a manual list. llvm-svn: 206739
2014-04-21 10:20:10 +02:00
#ifndef MODULE_ANALYSIS
#define MODULE_ANALYSIS(NAME, CREATE_PASS)
#endif
[CG] Add a new pass manager printer pass for the old call graph and 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
2016-03-10 12:24:11 +01:00
MODULE_ANALYSIS("callgraph", CallGraphAnalysis())
[PM] Wire the analysis passes (such as they are) into the registry, and teach the opt driver to use it rather than a manual list. llvm-svn: 206739
2014-04-21 10:20:10 +02:00
MODULE_ANALYSIS("lcg", LazyCallGraphAnalysis())
[PM] Port ModuleSummaryIndex analysis to new pass manager Summary: Port the ModuleSummaryAnalysisWrapperPass to the new pass manager. Use it in the ported BitcodeWriterPass (similar to how we use the legacy ModuleSummaryAnalysisWrapperPass in the legacy WriteBitcodePass). Also, pass the -module-summary opt flag through to the new pass manager pipeline and through to the bitcode writer pass, and add a test that uses it. Reviewers: mehdi_amini Subscribers: llvm-commits, mehdi_amini Differential Revision: https://reviews.llvm.org/D23439 llvm-svn: 278508
2016-08-12 15:53:02 +02:00
MODULE_ANALYSIS("module-summary", ModuleSummaryIndexAnalysis())
[PM] Add a collection of no-op analysis passes and switch the new pass manager tests to use them and be significantly more comprehensive. This, naturally, uncovered a bug where the CGSCC pass manager wasn't printing analyses when they were run. The only remaining core manipulator is I think an invalidate pass similar to the require pass. That'll be next. =] llvm-svn: 225240
2015-01-06 03:50:06 +01:00
MODULE_ANALYSIS("no-op-module", NoOpModuleAnalysis())
Reapply r271728 after adding move cobstructor for ProfileSummaryInfo llvm-svn: 271745
2016-06-04 00:54:26 +02:00
MODULE_ANALYSIS("profile-summary", ProfileSummaryAnalysis())
[stack-safety] Empty local passes for Stack Safety Global Analysis Reviewers: eugenis, vlad.tsyrklevich Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D54541 llvm-svn: 347610
2018-11-27 00:05:48 +01:00
MODULE_ANALYSIS("stack-safety", StackSafetyGlobalAnalysis())
Separate the Verifier into an analysis and a transformation pass and 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 This reapplies r268937 without modifications. llvm-svn: 268966
2016-05-09 21:57:29 +02:00
MODULE_ANALYSIS("verify", VerifierAnalysis())
[New PM] Introducing PassInstrumentation framework Pass Execution Instrumentation interface enables customizable instrumentation of pass execution, as per "RFC: Pass Execution Instrumentation interface" posted 06/07/2018 on llvm-dev@ The intent is to provide a common machinery to implement all the pass-execution-debugging features like print-before/after, opt-bisect, time-passes etc. Here we get a basic implementation consisting of: * PassInstrumentationCallbacks class that handles registration of callbacks and access to them. * PassInstrumentation class that handles instrumentation-point interfaces that call into PassInstrumentationCallbacks. * Callbacks accept StringRef which is just a name of the Pass right now. There were some ideas to pass an opaque wrapper for the pointer to pass instance, however it appears that pointer does not actually identify the instance (adaptors and managers might have the same address with the pass they govern). Hence it was decided to go simple for now and then later decide on what the proper mental model of identifying a "pass in a phase of pipeline" is. * Callbacks accept llvm::Any serving as a wrapper for const IRUnit*, to remove direct dependencies on different IRUnits (e.g. Analyses). * PassInstrumentationAnalysis analysis is explicitly requested from PassManager through usual AnalysisManager::getResult. All pass managers were updated to run that to get PassInstrumentation object for instrumentation calls. * Using tuples/index_sequence getAnalysisResult helper to extract generic AnalysisManager's extra args out of a generic PassManager's extra args. This is the only way I was able to explicitly run getResult for PassInstrumentationAnalysis out of a generic code like PassManager::run or RepeatedPass::run. TODO: Upon lengthy discussions we agreed to accept this as an initial implementation and then get rid of getAnalysisResult by improving RepeatedPass implementation. * PassBuilder takes PassInstrumentationCallbacks object to pass it further into PassInstrumentationAnalysis. Callbacks registration should be performed directly through PassInstrumentationCallbacks. * new-pm tests updated to account for PassInstrumentationAnalysis being run * Added PassInstrumentation tests to PassBuilderCallbacks unit tests. Other unit tests updated with registration of the now-required PassInstrumentationAnalysis. Made getName helper to return std::string (instead of StringRef initially) to fix asan builtbot failures on CGSCC tests. Reviewers: chandlerc, philip.pfaffe Differential Revision: https://reviews.llvm.org/D47858 llvm-svn: 342664
2018-09-20 19:08:45 +02:00
MODULE_ANALYSIS("pass-instrumentation", PassInstrumentationAnalysis(PIC))
[NewPM] Second attempt at porting ASan This is the second attempt to port ASan to new PM after D52739. This takes the initialization requried by ASan from the Module by moving it into a separate class with it's own analysis that the new PM ASan can use. Changes: - Split AddressSanitizer into 2 passes: 1 for the instrumentation on the function, and 1 for the pass itself which creates an instance of the first during it's run. The same is done for AddressSanitizerModule. - Add new PM AddressSanitizer and AddressSanitizerModule. - Add legacy and new PM analyses for reading data needed to initialize ASan with. - Removed DominatorTree dependency from ASan since it was unused. - Move GlobalsMetadata and ShadowMapping out of anonymous namespace since the new PM analysis holds these 2 classes and will need to expose them. Differential Revision: https://reviews.llvm.org/D56470 llvm-svn: 353985
2019-02-13 23:22:48 +01:00
MODULE_ANALYSIS("asan-globals-md", ASanGlobalsMetadataAnalysis())
[llvm] Add interface to drive inlining decision using ML model Summary: This change introduces InliningAdvisor (and related APIs), the interface that abstracts decision making away from the inlining pass. We will use this interface to delegate decision making to a trained ML model, subsequently (see referenced RFC). RFC: http://lists.llvm.org/pipermail/llvm-dev/2020-April/140763.html Reviewers: davidxl, eraman, dblaikie Subscribers: mgorny, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D79042
2020-04-28 22:25:15 +02:00
MODULE_ANALYSIS("inline-advisor", InlineAdvisorAnalysis())
[IRSim] Adding wrapper pass for IRSimilarityIdentfier This introduces an analysis pass that wraps IRSimilarityIdentifier, and adds a printer pass to examine in what function similarities are being found. Test for what the printer pass can find are in test/Analysis/IRSimilarityIdentifier. Reviewed by: paquette, jroelofs Differential Revision: https://reviews.llvm.org/D86973
2020-09-17 23:29:43 +02:00
MODULE_ANALYSIS("ir-similarity", IRSimilarityAnalysis())
[PM/AA] Teach the AAManager how to handle module analyses in addition to function analyses, and use it to wire up globals-aa to the new pass manager. llvm-svn: 263211
2016-03-11 10:15:11 +01:00
#ifndef MODULE_ALIAS_ANALYSIS
[CFLAA] Split into Anders+Steens analysis. StratifiedSets (as implemented) is very fast, but its accuracy is also limited. If we take a more aggressive andersens-like approach, we can be way more accurate, but we'll also end up being slower. So, we've decided to split CFLAA into CFLSteensAA and CFLAndersAA. Long-term, we want to end up in a place where CFLSteens is queried first; if it can provide an answer, great (since queries are basically map lookups). Otherwise, we'll fall back to CFLAnders, BasicAA, etc. This patch splits everything out so we can try to do something like that when we get a reasonable CFLAnders implementation. Patch by Jia Chen. Differential Revision: http://reviews.llvm.org/D21910 llvm-svn: 274589
2016-07-06 02:26:41 +02:00
#define MODULE_ALIAS_ANALYSIS(NAME, CREATE_PASS) \
[PM/AA] Teach the AAManager how to handle module analyses in addition to function analyses, and use it to wire up globals-aa to the new pass manager. llvm-svn: 263211
2016-03-11 10:15:11 +01:00
MODULE_ANALYSIS(NAME, CREATE_PASS)
#endif
MODULE_ALIAS_ANALYSIS("globals-aa", GlobalsAA())
#undef MODULE_ALIAS_ANALYSIS
[PM] Wire the analysis passes (such as they are) into the registry, and teach the opt driver to use it rather than a manual list. llvm-svn: 206739
2014-04-21 10:20:10 +02:00
#undef MODULE_ANALYSIS
[PM] Add a nice low-tech registry of passes as a boring macro expansion file. This will make it easy to scale up the number of passes supported. Currently, it just supports the function and module transformation passes that were already supported in the opt tool explicitly. llvm-svn: 206737
2014-04-21 10:08:50 +02:00
#ifndef MODULE_PASS
#define MODULE_PASS(NAME, CREATE_PASS)
#endif
[PM] Port the always inliner to the new pass manager in a much more minimal and boring form than the old pass manager's version. This pass does the very minimal amount of work necessary to inline functions declared as always-inline. It doesn't support a wide array of things that the legacy pass manager did support, but is alse ... about 20 lines of code. So it has that going for it. Notably things this doesn't support: - Array alloca merging - To support the above, bottom-up inlining with careful history tracking and call graph updates - DCE of the functions that become dead after this inlining. - Inlining through call instructions with the always_inline attribute. Instead, it focuses on inlining functions with that attribute. The first I've omitted because I'm hoping to just turn it off for the primary pass manager. If that doesn't pan out, I can add it here but it will be reasonably expensive to do so. The second should really be handled by running global-dce after the inliner. I don't want to re-implement the non-trivial logic necessary to do comdat-correct DCE of functions. This means the -O0 pipeline will have to be at least 'always-inline,global-dce', but that seems reasonable to me. If others are seriously worried about this I'd like to hear about it and understand why. Again, this is all solveable by factoring that logic into a utility and calling it here, but I'd like to wait to do that until there is a clear reason why the existing pass-based factoring won't work. The final point is a serious one. I can fairly easily add support for this, but it seems both costly and a confusing construct for the use case of the always inliner running at -O0. This attribute can of course still impact the normal inliner easily (although I find that a questionable re-use of the same attribute). I've started a discussion to sort out what semantics we want here and based on that can figure out if it makes sense ta have this complexity at O0 or not. One other advantage of this design is that it should be quite a bit faster due to checking for whether the function is a viable candidate for inlining exactly once per function instead of doing it for each call site. Anyways, hopefully a reasonable starting point for this pass. Differential Revision: https://reviews.llvm.org/D23299 llvm-svn: 278896
2016-08-17 04:56:20 +02:00
MODULE_PASS("always-inline", AlwaysInlinerPass())
[Attributor] Pass infrastructure and fixpoint framework NOTE: Note that no attributes are derived yet. This patch will not go in alone but only with others that derive attributes. The framework is split for review purposes. This commit introduces the Attributor pass infrastructure and fixpoint iteration framework. Further patches will introduce abstract attributes into this framework. In a nutshell, the Attributor will update instances of abstract arguments until a fixpoint, or a "timeout", is reached. Communication between the Attributor and the abstract attributes that are derived is restricted to the AbstractState and AbstractAttribute interfaces. Please see the file comment in Attributor.h for detailed information including design decisions and typical use case. Also consider the class documentation for Attributor, AbstractState, and AbstractAttribute. Reviewers: chandlerc, homerdin, hfinkel, fedor.sergeev, sanjoy, spatel, nlopes, nicholas, reames Subscribers: mehdi_amini, mgorny, hiraditya, bollu, steven_wu, dexonsmith, dang, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D59918 llvm-svn: 362578
2019-06-05 05:02:24 +02:00
MODULE_PASS("attributor", AttributorPass())
Add pass to add !annotate metadata from @llvm.global.annotations. This patch adds a new pass to add !annotation metadata for entries in @llvm.global.anotations, which is generated using __attribute__((annotate("_name"))) on functions in Clang. This has been discussed on llvm-dev as part of RFC: Combining Annotation Metadata and Remarks http://lists.llvm.org/pipermail/llvm-dev/2020-November/146393.html Reviewed By: thegameg Differential Revision: https://reviews.llvm.org/D91195
2020-11-16 10:49:04 +01:00
MODULE_PASS("annotation2metadata", Annotation2MetadataPass())
[OpenMP] Add OpenMPOpt as a Module pass Summary: This patch registers OpenMPOpt as a Module pass in addition to a CGSCC pass. This is so certain optimzations that are sensitive to intact call-sites can happen before inlining. The old `openmpopt` pass name is changed to `openmp-opt-cgscc` and `openmp-opt` calls the Module pass. The current module pass only runs a single check but will be expanded in the future. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D99202
2021-03-24 15:11:32 +01:00
MODULE_PASS("openmp-opt", OpenMPOptPass())
Add CalledValuePropagation pass This patch adds a new pass for attaching !callees metadata to indirect call sites. The pass propagates values to call sites by performing an IPSCCP-like analysis using the generic sparse propagation solver. For indirect call sites having a small set of possible callees, the attached metadata indicates what those callees are. The metadata can be used to facilitate optimizations like intersecting the function attributes of the possible callees, refining the call graph, performing indirect call promotion, etc. Differential Revision: https://reviews.llvm.org/D37355 llvm-svn: 316576
2017-10-25 15:40:08 +02:00
MODULE_PASS("called-value-propagation", CalledValuePropagationPass())
[ThinLTO] Handle chains of aliases At -O0, globalopt is not run during the compile step, and we can have a chain of an alias having an immediate aliasee of another alias. The summaries are constructed assuming aliases in a canonical form (flattened chains), and as a result only the base object but no intermediate aliases were preserved. Fix by adding a pass that canonicalize aliases, which ensures each alias is a direct alias of the base object. Reviewers: pcc, davidxl Subscribers: mehdi_amini, inglorion, eraman, steven_wu, dexonsmith, arphaman, llvm-commits Differential Revision: https://reviews.llvm.org/D54507 llvm-svn: 350423
2019-01-04 20:04:54 +01:00
MODULE_PASS("canonicalize-aliases", CanonicalizeAliasesPass())
Recommit r335794 "Add support for generating a call graph profile from Branch Frequency Info." with fix for removed functions. llvm-svn: 337140
2018-07-16 02:28:24 +02:00
MODULE_PASS("cg-profile", CGProfilePass())
[PM] Port ConstantMerge to the new pass manager. llvm-svn: 268582
2016-05-05 02:51:09 +02:00
MODULE_PASS("constmerge", ConstantMergePass())
[PM] Port CrossDSOCFI to the new pass manager. llvm-svn: 274962
2016-07-09 05:25:35 +02:00
MODULE_PASS("cross-dso-cfi", CrossDSOCFIPass())
[PM] Port DeadArgumentElimination to the new PM The approach taken here follows r267631. deadarghaX0r should be easy to port when the time comes to add new-PM support to bugpoint. llvm-svn: 272507
2016-06-12 11:16:39 +02:00
MODULE_PASS("deadargelim", DeadArgumentEliminationPass())
[PM] Port EliminateAvailableExternally pass to the new pass manager. llvm-svn: 268599
2016-05-05 04:37:32 +02:00
MODULE_PASS("elim-avail-extern", EliminateAvailableExternallyPass())
[BlockExtract][NewPM] Port -extract-blocks to NPM Reviewed By: thakis Differential Revision: https://reviews.llvm.org/D89015
2020-10-08 00:15:09 +02:00
MODULE_PASS("extract-blocks", BlockExtractorPass())
[attrs] Split off the forced attributes utility into its own pass that is (by default) run much earlier than FuncitonAttrs proper. This allows forcing optnone or other widely impactful attributes. It is also a bit simpler as the force attribute behavior needs no specific iteration order. I've added the pass into the default module pass pipeline and LTO pass pipeline which mirrors where function attrs itself was being run. Differential Revision: http://reviews.llvm.org/D15668 llvm-svn: 256465
2015-12-27 09:13:45 +01:00
MODULE_PASS("forceattrs", ForceFunctionAttrsPass())
[PM] Port FunctionImport Pass to new PM Summary: Port FunctionImport Pass to new PM. Reviewers: mehdi_amini, davide Subscribers: davidxl, llvm-commits Differential Revision: https://reviews.llvm.org/D22475 llvm-svn: 275916
2016-07-18 23:22:24 +02:00
MODULE_PASS("function-import", FunctionImportPass())
Function Specialization Pass This adds a function specialization pass to LLVM. Constant parameters like function pointers and constant globals are propagated to the callee by specializing the function. This is a first version with a number of limitations: - The pass is off by default, so needs to be enabled on the command line, - It does not handle specialization of recursive functions, - It does not yet handle constants and constant ranges, - Only 1 argument per function is specialised, - The cost-model could be further looked into, and perhaps related, - We are not yet caching analysis results. This is based on earlier work by Matthew Simpson (D36432) and Vinay Madhusudan. More recently this was also discussed on the list, see: https://lists.llvm.org/pipermail/llvm-dev/2021-March/149380.html. The motivation for this work is that function specialisation often comes up as a reason for performance differences of generated code between LLVM and GCC, which has this enabled by default from optimisation level -O3 and up. And while this certainly helps a few cpu benchmark cases, this also triggers in real world codes and is thus a generally useful transformation to have in LLVM. Function specialisation has great potential to increase compile-times and code-size. The summary from some investigations with this patch is: - Compile-time increases for short compile jobs is high relatively, but the increase in absolute numbers still low. - For longer compile-jobs, the extra compile time is around 1%, and very much in line with GCC. - It is difficult to blame one thing for compile-time increases: it looks like everywhere a little bit more time is spent processing more functions and instructions. - But the function specialisation pass itself is not very expensive; it doesn't show up very high in the profile of the optimisation passes. The goal of this work is to reach parity with GCC which means that eventually we would like to get this enabled by default. But first we would like to address some of the limitations before that. Differential Revision: https://reviews.llvm.org/D93838
2021-05-04 16:12:44 +02:00
MODULE_PASS("function-specialization", FunctionSpecializationPass())
[IPO/GlobalDCE] Port to the new pass manager. Differential Revision: http://reviews.llvm.org/D19782 llvm-svn: 268425
2016-05-03 21:39:15 +02:00
MODULE_PASS("globaldce", GlobalDCEPass())
PM: Port GlobalOpt to the new pass manager llvm-svn: 267499
2016-04-26 02:28:01 +02:00
MODULE_PASS("globalopt", GlobalOptPass())
[GlobalSplit] Port to the new pass manager. llvm-svn: 287511
2016-11-21 01:28:23 +01:00
MODULE_PASS("globalsplit", GlobalSplitPass())
Add support for new pass manager Modified the testcases to use both pass managers Use single commandline flag for both pass managers. Differential Revision: https://reviews.llvm.org/D52708 Reviewers: sebpop, tejohnson, brzycki, SirishP Reviewed By: tejohnson, brzycki llvm-svn: 343662
2018-10-03 07:55:20 +02:00
MODULE_PASS("hotcoldsplit", HotColdSplittingPass())
hwasan: Initialize the pass only once. This will let us instrument globals during initialization. This required making the new PM pass a module pass, which should still provide access to analyses via the ModuleAnalysisManager. Differential Revision: https://reviews.llvm.org/D64843 llvm-svn: 366379
2019-07-17 23:45:19 +02:00
MODULE_PASS("hwasan", HWAddressSanitizerPass(false, false))
MODULE_PASS("khwasan", HWAddressSanitizerPass(true, true))
[attrs] Extract the pure inference of function attributes into a standalone pass. There is no call graph or even interesting analysis for this part of function attributes -- it is literally inferring attributes based on the target library identification. As such, we can do it using a much simpler module pass that just walks the declarations. This can also happen much earlier in the pass pipeline which has benefits for any number of other passes. In the process, I've cleaned up one particular aspect of the logic which was necessary in order to separate the two passes cleanly. It now counts inferred attributes independently rather than just counting all the inferred attributes as one, and the counts are more clearly explained. The two test cases we had for this code path are both ... woefully inadequate and copies of each other. I've kept the superset test and updated it. We need more testing here, but I had to pick somewhere to stop fixing everything broken I saw here. Differential Revision: http://reviews.llvm.org/D15676 llvm-svn: 256466
2015-12-27 09:41:34 +01:00
MODULE_PASS("inferattrs", InferFunctionAttrsPass())
[llvm] Add interface to drive inlining decision using ML model Summary: This change introduces InliningAdvisor (and related APIs), the interface that abstracts decision making away from the inlining pass. We will use this interface to delegate decision making to a trained ML model, subsequently (see referenced RFC). RFC: http://lists.llvm.org/pipermail/llvm-dev/2020-April/140763.html Reviewers: davidxl, eraman, dblaikie Subscribers: mgorny, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D79042
2020-04-28 22:25:15 +02:00
MODULE_PASS("inliner-wrapper", ModuleInlinerWrapperPass())
[NewPM][Inliner] Move the 'always inliner' case in the same CGSCC pass as 'regular' inliner Expanding from D94808 - we ensure the same InlineAdvisor is used by both InlinerPass instances. The notion of mandatory inlining is moved into the core InlineAdvisor: advisors anyway have to handle that case, so this change also factors out that a bit better. Differential Revision: https://reviews.llvm.org/D94825
2021-01-15 22:56:57 +01:00
MODULE_PASS("inliner-wrapper-no-mandatory-first", ModuleInlinerWrapperPass(
[Passes] Add relative lookup table converter pass Lookup tables generate non PIC-friendly code, which requires dynamic relocation as described in: https://bugs.llvm.org/show_bug.cgi?id=45244 This patch adds a new pass that converts lookup tables to relative lookup tables to make them PIC-friendly. Differential Revision: https://reviews.llvm.org/D94355
2020-12-29 22:32:13 +01:00
getInlineParams(),
[NewPM][Inliner] Move the 'always inliner' case in the same CGSCC pass as 'regular' inliner Expanding from D94808 - we ensure the same InlineAdvisor is used by both InlinerPass instances. The notion of mandatory inlining is moved into the core InlineAdvisor: advisors anyway have to handle that case, so this change also factors out that a bit better. Differential Revision: https://reviews.llvm.org/D94825
2021-01-15 22:56:57 +01:00
false))
[PM] Port GCOVProfiler pass to the new pass manager llvm-svn: 271823
2016-06-05 07:12:23 +02:00
MODULE_PASS("insert-gcov-profiling", GCOVProfilerPass())
Add a module pass for order file instrumentation The basic idea of the pass is to use a circular buffer to log the execution ordering of the functions. We only log the function when it is first executed. We use a 8-byte hash to log the function symbol name. In this pass, we add three global variables: (1) an order file buffer: a circular buffer at its own llvm section. (2) a bitmap for each module: one byte for each function to say if the function is already executed. (3) a global index to the order file buffer. At the function prologue, if the function has not been executed (by checking the bitmap), log the function hash, then atomically increase the index. Differential Revision: https://reviews.llvm.org/D57463 llvm-svn: 355133
2019-02-28 21:13:38 +01:00
MODULE_PASS("instrorderfile", InstrOrderFilePass())
Port InstrProfiling pass to the new pass manager Differential Revision: http://reviews.llvm.org/D18126 llvm-svn: 266637
2016-04-18 19:47:38 +02:00
MODULE_PASS("instrprof", InstrProfiling())
Fix pass declaration order /NFC llvm-svn: 271824
2016-06-05 07:15:45 +02:00
MODULE_PASS("internalize", InternalizePass())
[PM] Introduce a utility pass that preserves no analyses. Use this to test that path of invalidation. This test actually shows redundant invalidation here that is really bad. I'm going to work on fixing that next, but wanted to commit the test harness now that its all working. llvm-svn: 225257
2015-01-06 10:06:35 +01:00
MODULE_PASS("invalidate<all>", InvalidateAllAnalysesPass())
[PM] Port Interprocedural SCCP to the new pass manager. llvm-svn: 268684
2016-05-05 23:05:36 +02:00
MODULE_PASS("ipsccp", IPSCCPPass())
[IRSim][IROutliner] Adding the extraction basics for the IROutliner. Extracting the similar regions is the first step in the IROutliner. Using the IRSimilarityIdentifier, we collect the SimilarityGroups and sort them by how many instructions will be removed. Each IRSimilarityCandidate is used to define an OutlinableRegion. Each region is ordered by their occurrence in the Module and the regions that are not compatible with previously outlined regions are discarded. Each region is then extracted with the CodeExtractor into its own function. We test that correctly extract in: test/Transforms/IROutliner/extraction.ll test/Transforms/IROutliner/address-taken.ll test/Transforms/IROutliner/outlining-same-globals.ll test/Transforms/IROutliner/outlining-same-constants.ll test/Transforms/IROutliner/outlining-different-structure.ll Recommit of bf899e891387d07dfd12de195ce2a16f62afd5e0 fixing memory leaks. Reviewers: paquette, jroelofs, yroux Differential Revision: https://reviews.llvm.org/D86975
2020-09-16 01:05:38 +02:00
MODULE_PASS("iroutliner", IROutlinerPass())
[IRSim] Adding wrapper pass for IRSimilarityIdentfier This introduces an analysis pass that wraps IRSimilarityIdentifier, and adds a printer pass to examine in what function similarities are being found. Test for what the printer pass can find are in test/Analysis/IRSimilarityIdentifier. Reviewed by: paquette, jroelofs Differential Revision: https://reviews.llvm.org/D86973
2020-09-17 23:29:43 +02:00
MODULE_PASS("print-ir-similarity", IRSimilarityAnalysisPrinterPass(dbgs()))
[LoopExtract][NewPM] Port -loop-extract to NPM -loop-extract-single is just -loop-extract on one loop. -loop-extract depended on -break-crit-edges and -loop-simplify in the legacy PM, but the NPM doesn't allow specifying pass dependencies like that, so manually add those passes to the RUN lines where necessary. Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D89016
2020-10-07 23:40:35 +02:00
MODULE_PASS("loop-extract", LoopExtractorPass())
[LowerTypeTests][NewPM] Add constructor that uses command line flags This matches the legacy PM pass by having one constructor use command line flags, and the other use parameters to the pass. This fixes all tests under Transforms/LowerTypeTests using NPM. Reviewed By: ychen, pcc Differential Revision: https://reviews.llvm.org/D87845
2020-09-17 19:36:39 +02:00
MODULE_PASS("lowertypetests", LowerTypeTestsPass())
[MetaRenamer][NewPM] Port metarenamer to NPM Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D88690
2020-10-01 20:49:45 +02:00
MODULE_PASS("metarenamer", MetaRenamerPass())
[NewPM] Port MergeFunctions pass This ports the MergeFunctions pass to the NewPM. This was rather straightforward, as no analyses are used. Additionally MergeFunctions needs to be conditionally enabled in the PassBuilder, but I left that part out of this patch. Differential Revision: https://reviews.llvm.org/D72537
2020-01-10 21:52:19 +01:00
MODULE_PASS("mergefunc", MergeFunctionsPass())
Fix test after renaming -name-anon-functions pass to -name-anon-globals llvm-svn: 281752
2016-09-16 19:18:16 +02:00
MODULE_PASS("name-anon-globals", NameAnonGlobalPass())
[PM] Sink the no-op pass parsing logic into the .def-based registry to simplify things. This will become more important as I add no-op analyses that want to re-use the logic we already have for analyses in the registry. For now, no functionality changed. llvm-svn: 225238
2015-01-06 03:37:55 +01:00
MODULE_PASS("no-op-module", NoOpModulePass())
[NewPM] Fix objc-arc-apelim pass typo
2020-12-23 06:40:43 +01:00
MODULE_PASS("objc-arc-apelim", ObjCARCAPElimPass())
[PM] Port PartialInlining to the new PM Differential revision: http://reviews.llvm.org/D21699 llvm-svn: 273894
2016-06-27 18:50:18 +02:00
MODULE_PASS("partial-inliner", PartialInlinerPass())
[PM] Port indirect call promotion pass to new pass manager llvm-svn: 269660
2016-05-16 18:31:07 +02:00
MODULE_PASS("pgo-icall-prom", PGOIndirectCallPromotion())
[PM] port IR based PGO prof-gen pass to new pass manager llvm-svn: 268710
2016-05-06 07:49:19 +02:00
MODULE_PASS("pgo-instr-gen", PGOInstrumentationGen())
[PM]: port IR based profUse pass to new pass manager llvm-svn: 269129
2016-05-10 23:59:52 +02:00
MODULE_PASS("pgo-instr-use", PGOInstrumentationUse())
Reapply r271728 after adding move cobstructor for ProfileSummaryInfo llvm-svn: 271745
2016-06-04 00:54:26 +02:00
MODULE_PASS("print-profile-summary", ProfileSummaryPrinterPass(dbgs()))
Revert r271728 as it breaks Windows build llvm-svn: 271738
2016-06-03 23:14:26 +02:00
MODULE_PASS("print-callgraph", CallGraphPrinterPass(dbgs()))
Reapply r271728 after adding move cobstructor for ProfileSummaryInfo llvm-svn: 271745
2016-06-04 00:54:26 +02:00
MODULE_PASS("print", PrintModulePass(dbgs()))
[LCG] Spell the printing pass pipeline name for the lazy call graph 'lcg' instead of just 'cg'. This makes it consistent with the analysis name of 'lcg'. No functionality changed. llvm-svn: 263103
2016-03-10 12:24:06 +01:00
MODULE_PASS("print-lcg", LazyCallGraphPrinterPass(dbgs()))
Add a super basic LazyCallGraph DOT printer. Access it through -passes=print-lcg-dot Let me know any suggestions for changing the rendering; I'm not particularly attached to what is implemented here. llvm-svn: 273082
2016-06-18 11:17:32 +02:00
MODULE_PASS("print-lcg-dot", LazyCallGraphDOTPrinterPass(dbgs()))
Port print-must-be-executed-contexts and print-mustexecute to NPM Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D90207
2020-10-27 03:57:39 +01:00
MODULE_PASS("print-must-be-executed-contexts", MustBeExecutedContextPrinterPass(dbgs()))
[stack-safety] Empty local passes for Stack Safety Global Analysis Reviewers: eugenis, vlad.tsyrklevich Subscribers: hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D54541 llvm-svn: 347610
2018-11-27 00:05:48 +01:00
MODULE_PASS("print-stack-safety", StackSafetyGlobalPrinterPass(dbgs()))
[NPM] Port module-debuginfo pass to the new pass manager Port pass to NPM and update tests in DebugInfo/Generic. Differential Revision: https://reviews.llvm.org/D89730
2020-10-19 23:31:17 +02:00
MODULE_PASS("print<module-debuginfo>", ModuleDebugInfoPrinterPass(dbgs()))
[Passes] Add relative lookup table converter pass Lookup tables generate non PIC-friendly code, which requires dynamic relocation as described in: https://bugs.llvm.org/show_bug.cgi?id=45244 This patch adds a new pass that converts lookup tables to relative lookup tables to make them PIC-friendly. Differential Revision: https://reviews.llvm.org/D94355
2020-12-29 22:32:13 +01:00
MODULE_PASS("rel-lookup-table-converter", RelLookupTableConverterPass())
[PM] port Rewrite Statepoints For GC to the new pass manager. Summary: The port is nearly straightforward. The only complication is related to the analyses handling, since one of the analyses used in this module pass is domtree, which is a function analysis. That requires asking for the results of each function and disallows a single interface for run-on-module pass action. Decided to copy-paste the main body of this pass. Most of its code is requesting analyses anyway, so not that much of a copy-paste. The rest of the code movement is to transform all the implementation helper functions like stripNonValidData into non-member statics. Extended all the related LLVM tests with new-pass-manager use. No failures. Reviewers: sanjoy, anna, reames Reviewed By: anna Subscribers: skatkov, llvm-commits Differential Revision: https://reviews.llvm.org/D41162 llvm-svn: 320796
2017-12-15 10:32:11 +01:00
MODULE_PASS("rewrite-statepoints-for-gc", RewriteStatepointsForGC())
[PM] Port SymbolRewriter to the new PM Differential Revision: https://reviews.llvm.org/D22703 llvm-svn: 276687
2016-07-25 22:52:00 +02:00
MODULE_PASS("rewrite-symbols", RewriteSymbolPass())
[FunctionAttrs] Rename functionattrs -> function-attrs To match NewPM pass name, and also for readability. Also rename rpo-functionattrs -> rpo-function-attrs while we're here. Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D84694
2020-07-28 18:08:08 +02:00
MODULE_PASS("rpo-function-attrs", ReversePostOrderFunctionAttrsPass())
[PM] Port the Sample FDO to new PM (part-2) llvm-svn: 271072
2016-05-28 01:20:16 +02:00
MODULE_PASS("sample-profile", SampleProfileLoaderPass())
[llvm][NFC] Factor out inlining pipeline as a module pipeline. Summary: This simplifies testing in scenarios where we want to set up module-wide analyses for inlining. The patch enables treating inlining and its function cleanups, as a module pass. The alternative would be for tests to describe the pipeline, which is tedious and adds maintenance overhead. Reviewers: davidxl, dblaikie, jdoerfert, sstefan1 Subscribers: hiraditya, steven_wu, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D78512
2020-04-20 20:05:29 +02:00
MODULE_PASS("scc-oz-module-inliner",
[NewPM][Inliner] Move the 'always inliner' case in the same CGSCC pass as 'regular' inliner Expanding from D94808 - we ensure the same InlineAdvisor is used by both InlinerPass instances. The notion of mandatory inlining is moved into the core InlineAdvisor: advisors anyway have to handle that case, so this change also factors out that a bit better. Differential Revision: https://reviews.llvm.org/D94825
2021-01-15 22:56:57 +01:00
buildInlinerPipeline(OptimizationLevel::Oz, ThinOrFullLTOPhase::None))
[LoopExtract][NewPM] Port -loop-extract to NPM -loop-extract-single is just -loop-extract on one loop. -loop-extract depended on -break-crit-edges and -loop-simplify in the legacy PM, but the NPM doesn't allow specifying pass dependencies like that, so manually add those passes to the RUN lines where necessary. Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D89016
2020-10-07 23:40:35 +02:00
MODULE_PASS("loop-extract-single", LoopExtractorPass(1))
[NewPM] Port strip* passes to NPM strip-nondebug and strip-debug-declare have no existing associated tests Reviewed By: ychen Differential Revision: https://reviews.llvm.org/D87639
2020-09-14 23:37:46 +02:00
MODULE_PASS("strip", StripSymbolsPass())
MODULE_PASS("strip-dead-debug-info", StripDeadDebugInfoPass())
[CSSPGO] Pseudo probe instrumentation pass This change introduces a pseudo probe instrumentation pass for block instrumentation. Please refer to https://reviews.llvm.org/D86193 for the whole story. Given the following LLVM IR: ``` define internal void @foo2(i32 %x, void (i32)* %f) !dbg !4 { bb0: %cmp = icmp eq i32 %x, 0 br i1 %cmp, label %bb1, label %bb2 bb1: br label %bb3 bb2: br label %bb3 bb3: ret void } ``` The instrumented IR will look like below. Note that each llvm.pseudoprobe intrinsic call represents a pseudo probe at a block, of which the first parameter is the GUID of the probe’s owner function and the second parameter is the probe’s ID. ``` define internal void @foo2(i32 %x, void (i32)* %f) !dbg !4 { bb0: %cmp = icmp eq i32 %x, 0 call void @llvm.pseudoprobe(i64 837061429793323041, i64 1) br i1 %cmp, label %bb1, label %bb2 bb1: call void @llvm.pseudoprobe(i64 837061429793323041, i64 2) br label %bb3 bb2: call void @llvm.pseudoprobe(i64 837061429793323041, i64 3) br label %bb3 bb3: call void @llvm.pseudoprobe(i64 837061429793323041, i64 4) ret void } ``` Reviewed By: wmi Differential Revision: https://reviews.llvm.org/D86499
2020-08-25 02:52:47 +02:00
MODULE_PASS("pseudo-probe", SampleProfileProbePass(TM))
[PM] Port StripDeadPrototypes to the new pass manager This is a really straightforward port. Also adds a test for the pass, since it only seemed to be tested tangentially before. llvm-svn: 251726
2015-10-31 00:28:12 +01:00
MODULE_PASS("strip-dead-prototypes", StripDeadPrototypesPass())
[NewPM] Port strip* passes to NPM strip-nondebug and strip-debug-declare have no existing associated tests Reviewed By: ychen Differential Revision: https://reviews.llvm.org/D87639
2020-09-14 23:37:46 +02:00
MODULE_PASS("strip-debug-declare", StripDebugDeclarePass())
MODULE_PASS("strip-nondebug", StripNonDebugSymbolsPass())
[NPM] Port strip nonlinetable debuginfo pass to the new pass manager Fixes a few tests in llvm/test/Transforms/Utils. Differential Revision: https://reviews.llvm.org/D88762
2020-10-03 01:18:47 +02:00
MODULE_PASS("strip-nonlinetable-debuginfo", StripNonLineTableDebugInfoPass())
Add a pass to generate synthetic function entry counts. Summary: This pass synthesizes function entry counts by traversing the callgraph and using the relative block frequencies of the callsites. The intended use of these counts is in inlining to determine hot/cold callsites in the absence of profile information. The pass is split into two files with the code that propagates the counts in a callgraph in a Utils file. I plan to add support for propagation in the thinlto link phase and the propagation code will be shared and hence this split. I did not add support to the old PM since hot callsite determination in inlining is not possible in old PM (although we could use hot callee heuristic with synthetic counts in the old PM it is not worth the effort tuning it) Reviewers: davidxl, silvas Subscribers: mgorny, mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D41604 llvm-svn: 322110
2018-01-09 20:39:35 +01:00
MODULE_PASS("synthetic-counts-propagation", SyntheticCountsPropagation())
[PM] Wire up support for explicitly running the verifier pass. The required functionality has been there for some time, but I never managed to actually wire it into the command line registry of passes. Let's do that. llvm-svn: 225144
2015-01-05 01:08:53 +01:00
MODULE_PASS("verify", VerifierPass())
[NewPM] Add unique-internal-linkage-names to PassRegistry.def Pass was already ported, just not properly hooked up.
2020-11-09 21:54:13 +01:00
MODULE_PASS("wholeprogramdevirt", WholeProgramDevirtPass())
[DFSan][NewPM] Port DataFlowSanitizer to NewPM Reviewed By: ychen, morehouse Differential Revision: https://reviews.llvm.org/D84707
2020-07-27 23:19:12 +02:00
MODULE_PASS("dfsan", DataFlowSanitizerPass())
[NewPM] Setup Passes for KASan and KMSan While ASan and MSan passes were already ported to new PM, the kernel variants weren't setup in the pipeline which makes the KASan and KMSan tests in Clang fail. Differential Revision: https://reviews.llvm.org/D61664 llvm-svn: 360313
2019-05-09 08:09:35 +02:00
MODULE_PASS("asan-module", ModuleAddressSanitizerPass(/*CompileKernel=*/false, false, true, false))
Insert module constructors in a module pass Summary: If we insert them from function pass some analysis may be missing or invalid. Fixes PR42877. Reviewers: eugenis, leonardchan Reviewed By: leonardchan Subscribers: hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D68832 > llvm-svn: 374481 Signed-off-by: Vitaly Buka <vitalybuka@google.com> llvm-svn: 374527
2019-10-11 10:47:03 +02:00
MODULE_PASS("msan-module", MemorySanitizerPass({}))
MODULE_PASS("tsan-module", ThreadSanitizerPass())
[NewPM] Setup Passes for KASan and KMSan While ASan and MSan passes were already ported to new PM, the kernel variants weren't setup in the pipeline which makes the KASan and KMSan tests in Clang fail. Differential Revision: https://reviews.llvm.org/D61664 llvm-svn: 360313
2019-05-09 08:09:35 +02:00
MODULE_PASS("kasan-module", ModuleAddressSanitizerPass(/*CompileKernel=*/true, false, true, false))
Reland the "[NewPM] Port Sancov" patch from rL365838. No functional changes were made to the patch since then. -------- [NewPM] Port Sancov This patch contains a port of SanitizerCoverage to the new pass manager. This one's a bit hefty. Changes: - Split SanitizerCoverageModule into 2 SanitizerCoverage for passing over functions and ModuleSanitizerCoverage for passing over modules. - ModuleSanitizerCoverage exists for adding 2 module level calls to initialization functions but only if there's a function that was instrumented by sancov. - Added legacy and new PM wrapper classes that own instances of the 2 new classes. - Update llvm tests and add clang tests. llvm-svn: 367053
2019-07-25 22:53:15 +02:00
MODULE_PASS("sancov-module", ModuleSanitizerCoveragePass())
[MemProf] Rename HeapProfiler to MemProfiler for consistency This is consistent with the clang option added in 7ed8124d46f94601d5f1364becee9cee8538265e, and the comments on the runtime patch in D87120. Differential Revision: https://reviews.llvm.org/D87622
2020-09-14 18:12:13 +02:00
MODULE_PASS("memprof-module", ModuleMemProfilerPass())
Add a transform pass to make the executable semantics of poison explicit in the IR Implements a transform pass which instruments IR such that poison semantics are made explicit. That is, it provides a (possibly partial) executable semantics for every instruction w.r.t. poison as specified in the LLVM LangRef. There are obvious parallels to the sanitizer tools, but this pass is focused purely on the semantics of LLVM IR, not any particular source language. The target audience for this tool is developers working on or targetting LLVM from a frontend. The idea is to be able to take arbitrary IR (with the assumption of known inputs), and evaluate it concretely after having made poison semantics explicit to detect cases where either a) the original code executes UB, or b) a transform pass introduces UB which didn't exist in the original program. At the moment, this is mostly the framework and still needs to be fleshed out. By reusing existing code we have decent coverage, but there's a lot of cases not yet handled. What's here is good enough to handle interesting cases though; for instance, one of the recent LFTR bugs involved UB being triggered by integer induction variables with nsw/nuw flags would be reported by the current code. (See comment in PoisonChecking.cpp for full explanation and context) Differential Revision: https://reviews.llvm.org/D64215 llvm-svn: 365536
2019-07-09 20:49:29 +02:00
MODULE_PASS("poison-checking", PoisonCheckingPass())
[CSSPGO] Introducing distribution factor for pseudo probe. Sample re-annotation is required in LTO time to achieve a reasonable post-inline profile quality. However, we have seen that such LTO-time re-annotation degrades profile quality. This is mainly caused by preLTO code duplication that is done by passes such as loop unrolling, jump threading, indirect call promotion etc, where samples corresponding to a source location are aggregated multiple times due to the duplicates. In this change we are introducing a concept of distribution factor for pseudo probes so that samples can be distributed for duplicated probes scaled by a factor. We hope that optimizations duplicating code well-maintain the branch frequency information (BFI) based on which probe distribution factors are calculated. Distribution factors are updated at the end of preLTO pipeline to reflect an estimated portion of the real execution count. This change also introduces a pseudo probe verifier that can be run after each IR passes to detect duplicated pseudo probes. A saturated distribution factor stands for 1.0. A pesudo probe will carry a factor with the value ranged from 0.0 to 1.0. A 64-bit integral distribution factor field that represents [0.0, 1.0] is associated to each block probe. Unfortunately this cannot be done for callsite probes due to the size limitation of a 32-bit Dwarf discriminator. A 7-bit distribution factor is used instead. Changes are also needed to the sample profile inliner to deal with prorated callsite counts. Call sites duplicated by PreLTO passes, when later on inlined in LTO time, should have the callees’s probe prorated based on the Prelink-computed distribution factors. The distribution factors should also be taken into account when computing hotness for inline candidates. Also, Indirect call promotion results in multiple callisites. The original samples should be distributed across them. This is fixed by adjusting the callisites' distribution factors. Reviewed By: wmi Differential Revision: https://reviews.llvm.org/D93264
2020-12-11 21:18:31 +01:00
MODULE_PASS("pseudo-probe-update", PseudoProbeUpdatePass())
[PM] Add a nice low-tech registry of passes as a boring macro expansion file. This will make it easy to scale up the number of passes supported. Currently, it just supports the function and module transformation passes that were already supported in the opt tool explicitly. llvm-svn: 206737
2014-04-21 10:08:50 +02:00
#undef MODULE_PASS
[PM] Add a new-PM-style CGSCC pass manager using the newly added LazyCallGraph analysis framework. Wire it up all the way through the opt driver and add some very basic testing that we can build pass pipelines including these components. Still a lot more to do in terms of testing that all of this works, but the basic pieces are here. There is a *lot* of boiler plate here. It's something I'm going to actively look at reducing, but I don't have any immediate ideas that don't end up making the code terribly complex in order to fold away the boilerplate. Until I figure out something to minimize the boilerplate, almost all of this is based on the code for the existing pass managers, copied and heavily adjusted to suit the needs of the CGSCC pass management layer. The actual CG management still has a bunch of FIXMEs in it. Notably, we don't do *any* updating of the CG as it is potentially invalidated. I wanted to get this in place to motivate the new analysis, and add update APIs to the analysis and the pass management layers in concert to make sure that the *right* APIs are present. llvm-svn: 206745
2014-04-21 13:12:00 +02:00
#ifndef CGSCC_ANALYSIS
#define CGSCC_ANALYSIS(NAME, CREATE_PASS)
#endif
[PM] Add a collection of no-op analysis passes and switch the new pass manager tests to use them and be significantly more comprehensive. This, naturally, uncovered a bug where the CGSCC pass manager wasn't printing analyses when they were run. The only remaining core manipulator is I think an invalidate pass similar to the require pass. That'll be next. =] llvm-svn: 225240
2015-01-06 03:50:06 +01:00
CGSCC_ANALYSIS("no-op-cgscc", NoOpCGSCCAnalysis())
[PM] Support invalidation of inner analysis managers from a pass over the outer IR unit. Summary: This never really got implemented, and was very hard to test before a lot of the refactoring changes to make things more robust. But now we can test it thoroughly and cleanly, especially at the CGSCC level. The core idea is that when an inner analysis manager proxy receives the invalidation event for the outer IR unit, it needs to walk the inner IR units and propagate it to the inner analysis manager for each of those units. For example, each function in the SCC needs to get an invalidation event when the SCC gets one. The function / module interaction is somewhat boring here. This really becomes interesting in the face of analysis-backed IR units. This patch effectively handles all of the CGSCC layer's needs -- both invalidating SCC analysis and invalidating function analysis when an SCC gets invalidated. However, this second aspect doesn't really handle the LoopAnalysisManager well at this point. That one will need some change of design in order to fully integrate, because unlike the call graph, the entire function behind a LoopAnalysis's results can vanish out from under us, and we won't even have a cached API to access. I'd like to try to separate solving the loop problems into a subsequent patch though in order to keep this more focused so I've adapted them to the API and updated the tests that immediately fail, but I've not added the level of testing and validation at that layer that I have at the CGSCC layer. An important aspect of this change is that the proxy for the FunctionAnalysisManager at the SCC pass layer doesn't work like the other proxies for an inner IR unit as it doesn't directly manage the FunctionAnalysisManager and invalidation or clearing of it. This would create an ever worsening problem of dual ownership of this responsibility, split between the module-level FAM proxy and this SCC-level FAM proxy. Instead, this patch changes the SCC-level FAM proxy to work in terms of the module-level proxy and defer to it to handle much of the updates. It only does SCC-specific invalidation. This will become more important in subsequent patches that support more complex invalidaiton scenarios. Reviewers: jlebar Subscribers: mehdi_amini, mcrosier, mzolotukhin, llvm-commits Differential Revision: https://reviews.llvm.org/D27197 llvm-svn: 289317
2016-12-10 07:34:44 +01:00
CGSCC_ANALYSIS("fam-proxy", FunctionAnalysisManagerCGSCCProxy())
[New PM] Introducing PassInstrumentation framework Pass Execution Instrumentation interface enables customizable instrumentation of pass execution, as per "RFC: Pass Execution Instrumentation interface" posted 06/07/2018 on llvm-dev@ The intent is to provide a common machinery to implement all the pass-execution-debugging features like print-before/after, opt-bisect, time-passes etc. Here we get a basic implementation consisting of: * PassInstrumentationCallbacks class that handles registration of callbacks and access to them. * PassInstrumentation class that handles instrumentation-point interfaces that call into PassInstrumentationCallbacks. * Callbacks accept StringRef which is just a name of the Pass right now. There were some ideas to pass an opaque wrapper for the pointer to pass instance, however it appears that pointer does not actually identify the instance (adaptors and managers might have the same address with the pass they govern). Hence it was decided to go simple for now and then later decide on what the proper mental model of identifying a "pass in a phase of pipeline" is. * Callbacks accept llvm::Any serving as a wrapper for const IRUnit*, to remove direct dependencies on different IRUnits (e.g. Analyses). * PassInstrumentationAnalysis analysis is explicitly requested from PassManager through usual AnalysisManager::getResult. All pass managers were updated to run that to get PassInstrumentation object for instrumentation calls. * Using tuples/index_sequence getAnalysisResult helper to extract generic AnalysisManager's extra args out of a generic PassManager's extra args. This is the only way I was able to explicitly run getResult for PassInstrumentationAnalysis out of a generic code like PassManager::run or RepeatedPass::run. TODO: Upon lengthy discussions we agreed to accept this as an initial implementation and then get rid of getAnalysisResult by improving RepeatedPass implementation. * PassBuilder takes PassInstrumentationCallbacks object to pass it further into PassInstrumentationAnalysis. Callbacks registration should be performed directly through PassInstrumentationCallbacks. * new-pm tests updated to account for PassInstrumentationAnalysis being run * Added PassInstrumentation tests to PassBuilderCallbacks unit tests. Other unit tests updated with registration of the now-required PassInstrumentationAnalysis. Made getName helper to return std::string (instead of StringRef initially) to fix asan builtbot failures on CGSCC tests. Reviewers: chandlerc, philip.pfaffe Differential Revision: https://reviews.llvm.org/D47858 llvm-svn: 342664
2018-09-20 19:08:45 +02:00
CGSCC_ANALYSIS("pass-instrumentation", PassInstrumentationAnalysis(PIC))
[PM] Add a new-PM-style CGSCC pass manager using the newly added LazyCallGraph analysis framework. Wire it up all the way through the opt driver and add some very basic testing that we can build pass pipelines including these components. Still a lot more to do in terms of testing that all of this works, but the basic pieces are here. There is a *lot* of boiler plate here. It's something I'm going to actively look at reducing, but I don't have any immediate ideas that don't end up making the code terribly complex in order to fold away the boilerplate. Until I figure out something to minimize the boilerplate, almost all of this is based on the code for the existing pass managers, copied and heavily adjusted to suit the needs of the CGSCC pass management layer. The actual CG management still has a bunch of FIXMEs in it. Notably, we don't do *any* updating of the CG as it is potentially invalidated. I wanted to get this in place to motivate the new analysis, and add update APIs to the analysis and the pass management layers in concert to make sure that the *right* APIs are present. llvm-svn: 206745
2014-04-21 13:12:00 +02:00
#undef CGSCC_ANALYSIS
#ifndef CGSCC_PASS
#define CGSCC_PASS(NAME, CREATE_PASS)
#endif
[PM] Port ArgumentPromotion to the new pass manager. 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
2017-02-10 00:46:27 +01:00
CGSCC_PASS("argpromotion", ArgumentPromotionPass())
[PM] Introduce a utility pass that preserves no analyses. Use this to test that path of invalidation. This test actually shows redundant invalidation here that is really bad. I'm going to work on fixing that next, but wanted to commit the test harness now that its all working. llvm-svn: 225257
2015-01-06 10:06:35 +01:00
CGSCC_PASS("invalidate<all>", InvalidateAllAnalysesPass())
[PM] Port the PostOrderFunctionAttrs pass to the new pass manager and 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
2016-02-18 12:03:11 +01:00
CGSCC_PASS("function-attrs", PostOrderFunctionAttrsPass())
[Attributor] Add an Attributor CGSCC pass and run it In addition to the module pass, this patch introduces a CGSCC pass that runs the Attributor on a strongly connected component of the call graph (both old and new PM). The Attributor was always design to be used on a subset of functions which makes this patch mostly mechanical. The one change is that we give up `norecurse` deduction in the module pass in favor of doing it during the CGSCC pass. This makes the interfaces simpler but can be revisited if needed. Reviewed By: hfinkel Differential Revision: https://reviews.llvm.org/D70767
2019-11-27 07:30:12 +01:00
CGSCC_PASS("attributor-cgscc", AttributorCGSCCPass())
[PM] Provide an initial, minimal port of the inliner to the new pass manager. This doesn't implement *every* feature of the existing inliner, but tries to implement the most important ones for building a functional optimization pipeline and beginning to sort out bugs, regressions, and other problems. Notable, but intentional omissions: - No alloca merging support. Why? Because it isn't clear we want to do this at all. Active discussion and investigation is going on to remove it, so for simplicity I omitted it. - No support for trying to iterate on "internally" devirtualized calls. Why? Because it adds what I suspect is inappropriate coupling for little or no benefit. We will have an outer iteration system that tracks devirtualization including that from function passes and iterates already. We should improve that rather than approximate it here. - Optimization remarks. Why? Purely to make the patch smaller, no other reason at all. The last one I'll probably work on almost immediately. But I wanted to skip it in the initial patch to try to focus the change as much as possible as there is already a lot of code moving around and both of these *could* be skipped without really disrupting the core logic. A summary of the different things happening here: 1) Adding the usual new PM class and rigging. 2) Fixing minor underlying assumptions in the inline cost analysis or inline logic that don't generally hold in the new PM world. 3) Adding the core pass logic which is in essence a loop over the calls in the nodes in the call graph. This is a bit duplicated from the old inliner, but only a handful of lines could realistically be shared. (I tried at first, and it really didn't help anything.) All told, this is only about 100 lines of code, and most of that is the mechanics of wiring up analyses from the new PM world. 4) Updating the LazyCallGraph (in the new PM) based on the *newly inlined* calls and references. This is very minimal because we cannot form cycles. 5) When inlining removes the last use of a function, eagerly nuking the body of the function so that any "one use remaining" inline cost heuristics are immediately refined, and queuing these functions to be completely deleted once inlining is complete and the call graph updated to reflect that they have become dead. 6) After all the inlining for a particular function, updating the LazyCallGraph and the CGSCC pass manager to reflect the function-local simplifications that are done immediately and internally by the inline utilties. These are the exact same fundamental set of CG updates done by arbitrary function passes. 7) Adding a bunch of test cases to specifically target CGSCC and other subtle aspects in the new PM world. Many thanks to the careful review from Easwaran and Sanjoy and others! Differential Revision: https://reviews.llvm.org/D24226 llvm-svn: 290161
2016-12-20 04:15:32 +01:00
CGSCC_PASS("inline", InlinerPass())
[OpenMP] Add OpenMPOpt as a Module pass Summary: This patch registers OpenMPOpt as a Module pass in addition to a CGSCC pass. This is so certain optimzations that are sensitive to intact call-sites can happen before inlining. The old `openmpopt` pass name is changed to `openmp-opt-cgscc` and `openmp-opt` calls the Module pass. The current module pass only runs a single check but will be expanded in the future. Reviewed By: jdoerfert Differential Revision: https://reviews.llvm.org/D99202
2021-03-24 15:11:32 +01:00
CGSCC_PASS("openmp-opt-cgscc", OpenMPOptCGSCCPass())
Re-land new pass manager coro-split and coro-elide This re-applies patches https://reviews.llvm.org/D71899 and https://reviews.llvm.org/D71900, which were reverted in https://reviews.llvm.org/rG11053a1cc61 and https://reviews.llvm.org/rGe999aa38d16. The underlying problem that caused two buildbots to fail with these patches is explained in https://reviews.llvm.org/rG26f356350bd -- older compliers disagree with the order in which the left- and right-hand side of an assignment in LazyCallGraph ought to be evaluated, which caused an assertion in SmallVector::operator[] to fire when the test suite was run.
2020-02-18 22:29:13 +01:00
CGSCC_PASS("coro-split", CoroSplitPass())
[PM] Sink the no-op pass parsing logic into the .def-based registry to simplify things. This will become more important as I add no-op analyses that want to re-use the logic we already have for analyses in the registry. For now, no functionality changed. llvm-svn: 225238
2015-01-06 03:37:55 +01:00
CGSCC_PASS("no-op-cgscc", NoOpCGSCCPass())
[PM] Add a new-PM-style CGSCC pass manager using the newly added LazyCallGraph analysis framework. Wire it up all the way through the opt driver and add some very basic testing that we can build pass pipelines including these components. Still a lot more to do in terms of testing that all of this works, but the basic pieces are here. There is a *lot* of boiler plate here. It's something I'm going to actively look at reducing, but I don't have any immediate ideas that don't end up making the code terribly complex in order to fold away the boilerplate. Until I figure out something to minimize the boilerplate, almost all of this is based on the code for the existing pass managers, copied and heavily adjusted to suit the needs of the CGSCC pass management layer. The actual CG management still has a bunch of FIXMEs in it. Notably, we don't do *any* updating of the CG as it is potentially invalidated. I wanted to get this in place to motivate the new analysis, and add update APIs to the analysis and the pass management layers in concert to make sure that the *right* APIs are present. llvm-svn: 206745
2014-04-21 13:12:00 +02:00
#undef CGSCC_PASS
[PM] Wire the analysis passes (such as they are) into the registry, and teach the opt driver to use it rather than a manual list. llvm-svn: 206739
2014-04-21 10:20:10 +02:00
#ifndef FUNCTION_ANALYSIS
#define FUNCTION_ANALYSIS(NAME, CREATE_PASS)
#endif
[PM/AA] Actually wire the AAManager I built for the new pass manager 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
2016-02-14 00:32:00 +01:00
FUNCTION_ANALYSIS("aa", AAManager())
Revert @llvm.assume with operator bundles (r289755-r289757) This creates non-linear behavior in the inliner (see more details in r289755's commit thread). llvm-svn: 290086
2016-12-19 09:22:17 +01:00
FUNCTION_ANALYSIS("assumptions", AssumptionAnalysis())
[PM] port Branch Frequency Analaysis pass to new PM llvm-svn: 268687
2016-05-05 23:13:27 +02:00
FUNCTION_ANALYSIS("block-freq", BlockFrequencyAnalysis())
[PM] Port Branch Probability Analysis pass to the new pass manager. Differential Revision: http://reviews.llvm.org/D19839 llvm-svn: 268601
2016-05-05 04:59:57 +02:00
FUNCTION_ANALYSIS("branch-prob", BranchProbabilityAnalysis())
[PM] Port domtree to the new pass manager (at last). This adds the domtree analysis to the new pass manager. The analysis returns the same DominatorTree result entity used by the old pass manager and essentially all of the code is shared. We just have different boilerplate for running and printing the analysis. I've converted one test to run in both modes just to make sure this is exercised while both are live in the tree. llvm-svn: 225969
2015-01-14 11:19:28 +01:00
FUNCTION_ANALYSIS("domtree", DominatorTreeAnalysis())
Introduce analysis pass to compute PostDominators in the new pass manager. NFC Differential Revision: http://reviews.llvm.org/D17537 llvm-svn: 261902
2016-02-25 18:54:07 +01:00
FUNCTION_ANALYSIS("postdomtree", PostDominatorTreeAnalysis())
Port DemandedBits to the new pass manager. Differential Revision: http://reviews.llvm.org/D18679 llvm-svn: 266699
2016-04-19 01:55:01 +02:00
FUNCTION_ANALYSIS("demanded-bits", DemandedBitsAnalysis())
Introduce DominanceFrontierAnalysis to the new PassManager to compute DominanceFrontier. NFC Differential Revision: http://reviews.llvm.org/D17570 llvm-svn: 261903
2016-02-25 18:54:15 +01:00
FUNCTION_ANALYSIS("domfrontier", DominanceFrontierAnalysis())
Add a Printer to the FunctionPropertiesAnalysis A printer pass and a lit test case was added. Reviewed By: mtrofin Differential Revision: https://reviews.llvm.org/D82523
2020-07-23 20:56:56 +02:00
FUNCTION_ANALYSIS("func-properties", FunctionPropertiesAnalysis())
[PM] Port LoopInfo to the new pass manager, adding both a LoopAnalysis pass and a LoopPrinterPass with the expected associated wiring. I've added a RUN line to the only test case (!!!) we have that actually prints loops. Everything seems to be working. This is somewhat exciting as this is the first analysis using another analysis to go in for the new pass manager. =D I also believe it is the last analysis necessary for porting instcombine, but of course I may yet discover more. llvm-svn: 226560
2015-01-20 11:58:50 +01:00
FUNCTION_ANALYSIS("loops", LoopAnalysis())
[PM] Port LVI to the new PM. This is a bit gnarly since LVI is maintaining its own cache. I think this port could be somewhat cleaner, but I'd rather not spend too much time on it while we still have the old pass hanging around and limiting how much we can clean things up. Once the old pass is gone it will be easier (less time spent) to clean it up anyway. This is the last dependency needed for porting JumpThreading which I'll do in a follow-up commit (there's no printer pass for LVI or anything to test it, so porting a pass that depends on it seems best). I've been mostly following: r269370 / D18834 which ported Dependence Analysis r268601 / D19839 which ported BPI llvm-svn: 272593
2016-06-14 00:01:25 +02:00
FUNCTION_ANALYSIS("lazy-value-info", LazyValueAnalysis())
[PM] Port of the DepndenceAnalysis to the new PM. Ported DA to the new PM by splitting the former DependenceAnalysis Pass into a DependenceInfo result type and DependenceAnalysisWrapperPass type and adding a new PM-style DependenceAnalysis analysis pass returning the DependenceInfo. Patch by Philip Pfaffe, most of the review by Justin. Differential Revision: http://reviews.llvm.org/D18834 llvm-svn: 269370
2016-05-13 00:19:39 +02:00
FUNCTION_ANALYSIS("da", DependenceAnalysis())
Reapply "[llvm] Native size estimator for training -Oz inliner" This reverts commit 9908a3b9f521c954cbf6adcec35b14b2f6c8da49. The fix was to exclude the content of TFUtils.h (automatically included in the LLVM_Analysis module, when LLVM_ENABLE_MODULES is enabled). Differential Revision: https://reviews.llvm.org/D82817
2020-07-13 23:12:32 +02:00
FUNCTION_ANALYSIS("inliner-size-estimator", InlineSizeEstimatorAnalysis())
[PM] Port memdep to the new pass manager. 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
2016-03-10 01:55:30 +01:00
FUNCTION_ANALYSIS("memdep", MemoryDependenceAnalysis())
[MemorySSA] Port to new pass manager Add support for the new pass manager to MemorySSA pass. Change MemorySSA to be computed eagerly upon construction. Change MemorySSAWalker to be owned by the MemorySSA object that creates it. Reviewers: dberlin, george.burgess.iv Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D19664 llvm-svn: 271432
2016-06-01 23:30:40 +02:00
FUNCTION_ANALYSIS("memoryssa", MemorySSAAnalysis())
Add a PhiValuesAnalysis pass to calculate the underlying values of phis This pass is being added in order to make the information available to BasicAA, which can't do caching of this information itself, but possibly this information may be useful for other passes. Incorporates code based on Daniel Berlin's implementation of Tarjan's algorithm. Differential Revision: https://reviews.llvm.org/D47893 llvm-svn: 335857
2018-06-28 16:13:06 +02:00
FUNCTION_ANALYSIS("phi-values", PhiValuesAnalysis())
Introduce RegionInfoAnalysis, which compute Region Tree in the new PassManager. NFC Differential Revision: http://reviews.llvm.org/D17571 llvm-svn: 261904
2016-02-25 18:54:25 +01:00
FUNCTION_ANALYSIS("regions", RegionInfoAnalysis())
[PM] Add a collection of no-op analysis passes and switch the new pass manager tests to use them and be significantly more comprehensive. This, naturally, uncovered a bug where the CGSCC pass manager wasn't printing analyses when they were run. The only remaining core manipulator is I think an invalidate pass similar to the require pass. That'll be next. =] llvm-svn: 225240
2015-01-06 03:50:06 +01:00
FUNCTION_ANALYSIS("no-op-function", NoOpFunctionAnalysis())
[OptRemarkEmitter] Port to new PM Summary: The main goal is to able to start using the new OptRemarkEmitter analysis from the LoopVectorizer. Since the vectorizer was recently converted to the new PM, it makes sense to convert this analysis as well. This pass is currently tested through the LoopDistribution pass, so I am also porting LoopDistribution to get coverage for this analysis with the new PM. Reviewers: davidxl, silvas Subscribers: llvm-commits, mzolotukhin Differential Revision: https://reviews.llvm.org/D22436 llvm-svn: 275810
2016-07-18 18:29:21 +02:00
FUNCTION_ANALYSIS("opt-remark-emit", OptimizationRemarkEmitterAnalysis())
[PM] Port ScalarEvolution to the new pass manager. This change makes ScalarEvolution a stand-alone object and just produces one from a pass as needed. Making this work well requires making the object movable, using references instead of overwritten pointers in a number of places, and other refactorings. I've also wired it up to the new pass manager and added a RUN line to a test to exercise it under the new pass manager. This includes basic printing support much like with other analyses. But there is a big and somewhat scary change here. Prior to this patch ScalarEvolution was never *actually* invalidated!!! Re-running the pass just re-wired up the various other analyses and didn't remove any of the existing entries in the SCEV caches or clear out anything at all. This might seem OK as everything in SCEV that can uses ValueHandles to track updates to the values that serve as SCEV keys. However, this still means that as we ran SCEV over each function in the module, we kept accumulating more and more SCEVs into the cache. At the end, we would have a SCEV cache with every value that we ever needed a SCEV for in the entire module!!! Yowzers. The releaseMemory routine would dump all of this, but that isn't realy called during normal runs of the pipeline as far as I can see. To make matters worse, there *is* actually a key that we don't update with value handles -- there is a map keyed off of Loop*s. Because LoopInfo *does* release its memory from run to run, it is entirely possible to run SCEV over one function, then over another function, and then lookup a Loop* from the second function but find an entry inserted for the first function! Ouch. To make matters still worse, there are plenty of updates that *don't* trip a value handle. It seems incredibly unlikely that today GVN or another pass that invalidates SCEV can update values in *just* such a way that a subsequent run of SCEV will incorrectly find lookups in a cache, but it is theoretically possible and would be a nightmare to debug. With this refactoring, I've fixed all this by actually destroying and recreating the ScalarEvolution object from run to run. Technically, this could increase the amount of malloc traffic we see, but then again it is also technically correct. ;] I don't actually think we're suffering from tons of malloc traffic from SCEV because if we were, the fact that we never clear the memory would seem more likely to have come up as an actual problem before now. So, I've made the simple fix here. If in fact there are serious issues with too much allocation and deallocation, I can work on a clever fix that preserves the allocations (while clearing the data) between each run, but I'd prefer to do that kind of optimization with a test case / benchmark that shows why we need such cleverness (and that can test that we actually make it faster). It's possible that this will make some things faster by making the SCEV caches have higher locality (due to being significantly smaller) so until there is a clear benchmark, I think the simple change is best. Differential Revision: http://reviews.llvm.org/D12063 llvm-svn: 245193
2015-08-17 04:08:17 +02:00
FUNCTION_ANALYSIS("scalar-evolution", ScalarEvolutionAnalysis())
[stack-safety] Empty local passes for Stack Safety Local Analysis Reviewers: eugenis, vlad.tsyrklevich Subscribers: mgorny, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D54502 llvm-svn: 347602
2018-11-26 22:57:47 +01:00
FUNCTION_ANALYSIS("stack-safety-local", StackSafetyAnalysis())
[PM] Rework how the TargetLibraryInfo pass integrates with the new pass manager to support the actual uses of it. =] When I ported instcombine to the new pass manager I discover that it didn't work because TLI wasn't available in the right places. This is a somewhat surprising and/or subtle aspect of the new pass manager design that came up before but I think is useful to be reminded of: While the new pass manager *allows* a function pass to query a module analysis, it requires that the module analysis is already run and cached prior to the function pass manager starting up, possibly with a 'require<foo>' style utility in the pass pipeline. This is an intentional hurdle because using a module analysis from a function pass *requires* that the module analysis is run prior to entering the function pass manager. Otherwise the other functions in the module could be in who-knows-what state, etc. A somewhat surprising consequence of this design decision (at least to me) is that you have to design a function pass that leverages a module analysis to do so as an optional feature. Even if that means your function pass does no work in the absence of the module analysis, you have to handle that possibility and remain conservatively correct. This is a natural consequence of things being able to invalidate the module analysis and us being unable to re-run it. And it's a generally good thing because it lets us reorder passes arbitrarily without breaking correctness, etc. This ends up causing problems in one case. What if we have a module analysis that is *definitionally* impossible to invalidate. In the places this might come up, the analysis is usually also definitionally trivial to run even while other transformation passes run on the module, regardless of the state of anything. And so, it follows that it is natural to have a hard requirement on such analyses from a function pass. It turns out, that TargetLibraryInfo is just such an analysis, and InstCombine has a hard requirement on it. The approach I've taken here is to produce an analysis that models this flexibility by making it both a module and a function analysis. This exposes the fact that it is in fact safe to compute at any point. We can even make it a valid CGSCC analysis at some point if that is useful. However, we don't want to have a copy of the actual target library info state for each function! This state is specific to the triple. The somewhat direct and blunt approach here is to turn TLI into a pimpl, with the state and mutators in the implementation class and the query routines primarily in the wrapper. Then the analysis can lazily construct and cache the implementations, keyed on the triple, and on-demand produce wrappers of them for each function. One minor annoyance is that we will end up with a wrapper for each function in the module. While this is a bit wasteful (one pointer per function) it seems tolerable. And it has the advantage of ensuring that we pay the absolute minimum synchronization cost to access this information should we end up with a nice parallel function pass manager in the future. We could look into trying to mark when analysis results are especially cheap to recompute and more eagerly GC-ing the cached results, or we could look at supporting a variant of analyses whose results are specifically *not* cached and expected to just be used and discarded by the consumer. Either way, these seem like incremental enhancements that should happen when we start profiling the memory and CPU usage of the new pass manager and not before. The other minor annoyance is that if we end up using the TLI in both a module pass and a function pass, those will be produced by two separate analyses, and thus will point to separate copies of the implementation state. While a minor issue, I dislike this and would like to find a way to cleanly allow a single analysis instance to be used across multiple IR unit managers. But I don't have a good solution to this today, and I don't want to hold up all of the work waiting to come up with one. This too seems like a reasonable thing to incrementally improve later. llvm-svn: 226981
2015-01-24 03:06:09 +01:00
FUNCTION_ANALYSIS("targetlibinfo", TargetLibraryAnalysis())
[PM] Port TTI to the new pass manager, introducing a TargetIRAnalysis to produce it. This adds a function to the TargetMachine that produces this analysis via a callback for each function. This in turn faves the way to produce a *different* TTI per-function with the correct subtarget cached. I've also done the necessary wiring in the opt tool to thread the target machine down and make it available to the pass registry so that we can construct this analysis from a target machine when available. llvm-svn: 227721
2015-02-01 11:11:22 +01:00
FUNCTION_ANALYSIS("targetir",
TM ? TM->getTargetIRAnalysis() : TargetIRAnalysis())
Separate the Verifier into an analysis and a transformation pass and 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 This reapplies r268937 without modifications. llvm-svn: 268966
2016-05-09 21:57:29 +02:00
FUNCTION_ANALYSIS("verify", VerifierAnalysis())
[New PM] Introducing PassInstrumentation framework Pass Execution Instrumentation interface enables customizable instrumentation of pass execution, as per "RFC: Pass Execution Instrumentation interface" posted 06/07/2018 on llvm-dev@ The intent is to provide a common machinery to implement all the pass-execution-debugging features like print-before/after, opt-bisect, time-passes etc. Here we get a basic implementation consisting of: * PassInstrumentationCallbacks class that handles registration of callbacks and access to them. * PassInstrumentation class that handles instrumentation-point interfaces that call into PassInstrumentationCallbacks. * Callbacks accept StringRef which is just a name of the Pass right now. There were some ideas to pass an opaque wrapper for the pointer to pass instance, however it appears that pointer does not actually identify the instance (adaptors and managers might have the same address with the pass they govern). Hence it was decided to go simple for now and then later decide on what the proper mental model of identifying a "pass in a phase of pipeline" is. * Callbacks accept llvm::Any serving as a wrapper for const IRUnit*, to remove direct dependencies on different IRUnits (e.g. Analyses). * PassInstrumentationAnalysis analysis is explicitly requested from PassManager through usual AnalysisManager::getResult. All pass managers were updated to run that to get PassInstrumentation object for instrumentation calls. * Using tuples/index_sequence getAnalysisResult helper to extract generic AnalysisManager's extra args out of a generic PassManager's extra args. This is the only way I was able to explicitly run getResult for PassInstrumentationAnalysis out of a generic code like PassManager::run or RepeatedPass::run. TODO: Upon lengthy discussions we agreed to accept this as an initial implementation and then get rid of getAnalysisResult by improving RepeatedPass implementation. * PassBuilder takes PassInstrumentationCallbacks object to pass it further into PassInstrumentationAnalysis. Callbacks registration should be performed directly through PassInstrumentationCallbacks. * new-pm tests updated to account for PassInstrumentationAnalysis being run * Added PassInstrumentation tests to PassBuilderCallbacks unit tests. Other unit tests updated with registration of the now-required PassInstrumentationAnalysis. Made getName helper to return std::string (instead of StringRef initially) to fix asan builtbot failures on CGSCC tests. Reviewers: chandlerc, philip.pfaffe Differential Revision: https://reviews.llvm.org/D47858 llvm-svn: 342664
2018-09-20 19:08:45 +02:00
FUNCTION_ANALYSIS("pass-instrumentation", PassInstrumentationAnalysis(PIC))
[NewPM] Introduce (GPU)DivergenceAnalysis in the new pass manager The GPUDivergenceAnalysis is now renamed to just "DivergenceAnalysis" since there is no conflict with LegacyDivergenceAnalysis. In the legacy PM, this analysis can only be used through the legacy DA serving as a wrapper. It is now made available as a pass in the new PM, and has no relation with the legacy DA. The new DA currently cannot handle irreducible control flow; its presence can cause the analysis to run indefinitely. The analysis is now modified to detect this and report all instructions in the function as divergent. This is super conservative, but allows the analysis to be used without hanging the compiler. Reviewed By: aeubanks Differential Revision: https://reviews.llvm.org/D96615
2021-02-16 05:56:45 +01:00
FUNCTION_ANALYSIS("divergence", DivergenceAnalysis())
[PM/AA] Teach the new pass manager to use pass-by-lambda for registering 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
2016-02-18 10:45:17 +01:00
#ifndef FUNCTION_ALIAS_ANALYSIS
#define FUNCTION_ALIAS_ANALYSIS(NAME, CREATE_PASS) \
FUNCTION_ANALYSIS(NAME, CREATE_PASS)
#endif
FUNCTION_ALIAS_ANALYSIS("basic-aa", BasicAA())
[CFLAA] Split into Anders+Steens analysis. StratifiedSets (as implemented) is very fast, but its accuracy is also limited. If we take a more aggressive andersens-like approach, we can be way more accurate, but we'll also end up being slower. So, we've decided to split CFLAA into CFLSteensAA and CFLAndersAA. Long-term, we want to end up in a place where CFLSteens is queried first; if it can provide an answer, great (since queries are basically map lookups). Otherwise, we'll fall back to CFLAnders, BasicAA, etc. This patch splits everything out so we can try to do something like that when we get a reasonable CFLAnders implementation. Patch by Jia Chen. Differential Revision: http://reviews.llvm.org/D21910 llvm-svn: 274589
2016-07-06 02:26:41 +02:00
FUNCTION_ALIAS_ANALYSIS("cfl-anders-aa", CFLAndersAA())
FUNCTION_ALIAS_ANALYSIS("cfl-steens-aa", CFLSteensAA())
[ObjCARCAA][NewPM] Add already ported objc-arc-aa to PassRegistry.def Also add missing AnalysisKey definition.
2020-09-26 09:18:42 +02:00
FUNCTION_ALIAS_ANALYSIS("objc-arc-aa", objcarc::ObjCARCAA())
[PM/AA] Wire up SCEVAA to the new pass manager's registry and test it. llvm-svn: 261409
2016-02-20 05:01:45 +01:00
FUNCTION_ALIAS_ANALYSIS("scev-aa", SCEVAA())
[PM/AA] Wire up the scoped-no-alias AA to the new pass manager's registry and test it. llvm-svn: 261410
2016-02-20 05:03:06 +01:00
FUNCTION_ALIAS_ANALYSIS("scoped-noalias-aa", ScopedNoAliasAA())
[tbaa] Rename type-based-aa -> tbaa For consistency with legacy pass name. Helps with 37 instances of "unknown pass name 'tbaa'" in check-llvm under NPM. Reviewed By: ychen Differential Revision: https://reviews.llvm.org/D84967
2020-07-30 01:44:22 +02:00
FUNCTION_ALIAS_ANALYSIS("tbaa", TypeBasedAA())
[PM/AA] Teach the new pass manager to use pass-by-lambda for registering 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
2016-02-18 10:45:17 +01:00
#undef FUNCTION_ALIAS_ANALYSIS
[PM] Wire the analysis passes (such as they are) into the registry, and teach the opt driver to use it rather than a manual list. llvm-svn: 206739
2014-04-21 10:20:10 +02:00
#undef FUNCTION_ANALYSIS
[PM] Add a nice low-tech registry of passes as a boring macro expansion file. This will make it easy to scale up the number of passes supported. Currently, it just supports the function and module transformation passes that were already supported in the opt tool explicitly. llvm-svn: 206737
2014-04-21 10:08:50 +02:00
#ifndef FUNCTION_PASS
#define FUNCTION_PASS(NAME, CREATE_PASS)
#endif
[PM/AA] Port alias analysis evaluator to the new pass manager, and use 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
2016-02-20 04:46:03 +01:00
FUNCTION_PASS("aa-eval", AAEvaluator())
[PM] Port ADCE to the new pass manager llvm-svn: 251725
2015-10-31 00:13:18 +01:00
FUNCTION_PASS("adce", ADCEPass())
[PM] Port Add discriminator pass to new PM llvm-svn: 272847
2016-06-15 23:51:30 +02:00
FUNCTION_PASS("add-discriminators", AddDiscriminatorsPass())
Another try to commit 323321 (aggressive instruction combine). llvm-svn: 323416
2018-01-25 13:06:32 +01:00
FUNCTION_PASS("aggressive-instcombine", AggressiveInstCombinePass())
Build assume from call Fix attempt this is part of the implementation of http://lists.llvm.org/pipermail/llvm-dev/2019-December/137632.html this patch gives the basis of building an assume to preserve all information from an instruction and add support for building an assume that preserve the information from a call.
2020-02-02 14:46:59 +01:00
FUNCTION_PASS("assume-builder", AssumeBuilderPass())
[NFC][DwarfDebug] Add test for variables with a single location which don't span their entire scope. The previous commit (6d1c40c171e) is an older version of the test. Reviewed By: aprantl, vsk Differential Revision: https://reviews.llvm.org/D79573
2020-05-07 13:41:20 +02:00
FUNCTION_PASS("assume-simplify", AssumeSimplifyPass())
[PM] Port AlignmentFromAssumptions to the new PM. This uses the "runImpl" pattern to share code between the old and new PM. llvm-svn: 272757
2016-06-15 08:18:01 +02:00
FUNCTION_PASS("alignment-from-assumptions", AlignmentFromAssumptionsPass())
Add !annotation metadata and remarks pass. This patch adds a new !annotation metadata kind which can be used to attach annotation strings to instructions. It also adds a new pass that emits summary remarks per function with the counts for each annotation kind. The intended uses cases for this new metadata is annotating 'interesting' instructions and the remarks should provide additional insight into transformations applied to a program. To motivate this, consider these specific questions we would like to get answered: * How many stores added for automatic variable initialization remain after optimizations? Where are they? * How many runtime checks inserted by a frontend could be eliminated? Where are the ones that did not get eliminated? Discussed on llvm-dev as part of 'RFC: Combining Annotation Metadata and Remarks' (http://lists.llvm.org/pipermail/llvm-dev/2020-November/146393.html) Reviewed By: thegameg, jdoerfert Differential Revision: https://reviews.llvm.org/D91188
2020-11-13 10:46:55 +01:00
FUNCTION_PASS("annotation-remarks", AnnotationRemarksPass())
[PM] Port BDCE to the new pass manager. llvm-svn: 270647
2016-05-25 03:57:04 +02:00
FUNCTION_PASS("bdce", BDCEPass())
[PM] Port BoundsChecking to the new PM. Registers it and everything, updates all the references, etc. Next patch will add support to Clang's `-fexperimental-new-pass-manager` path to actually enable BoundsChecking correctly. Differential Revision: https://reviews.llvm.org/D39084 llvm-svn: 318128
2017-11-14 02:30:04 +01:00
FUNCTION_PASS("bounds-checking", BoundsCheckingPass())
[PM] Port BreakCriticalEdges to the new PM. Differential Revision: https://reviews.llvm.org/D22688 llvm-svn: 276449
2016-07-22 20:04:25 +02:00
FUNCTION_PASS("break-crit-edges", BreakCriticalEdgesPass())
Recommit r317351 : Add CallSiteSplitting pass This recommit r317351 after fixing a buildbot failure. Original commit message: Summary: This change add a pass which tries to split a call-site to pass more constrained arguments if its argument is predicated in the control flow so that we can expose better context to the later passes (e.g, inliner, jump threading, or IPA-CP based function cloning, etc.). As of now we support two cases : 1) If a call site is dominated by an OR condition and if any of its arguments are predicated on this OR condition, try to split the condition with more constrained arguments. For example, in the code below, we try to split the call site since we can predicate the argument (ptr) based on the OR condition. Split from : if (!ptr || c) callee(ptr); to : if (!ptr) callee(null ptr) // set the known constant value else if (c) callee(nonnull ptr) // set non-null attribute in the argument 2) We can also split a call-site based on constant incoming values of a PHI For example, from : BB0: %c = icmp eq i32 %i1, %i2 br i1 %c, label %BB2, label %BB1 BB1: br label %BB2 BB2: %p = phi i32 [ 0, %BB0 ], [ 1, %BB1 ] call void @bar(i32 %p) to BB0: %c = icmp eq i32 %i1, %i2 br i1 %c, label %BB2-split0, label %BB1 BB1: br label %BB2-split1 BB2-split0: call void @bar(i32 0) br label %BB2 BB2-split1: call void @bar(i32 1) br label %BB2 BB2: %p = phi i32 [ 0, %BB2-split0 ], [ 1, %BB2-split1 ] llvm-svn: 317362
2017-11-03 21:41:16 +01:00
FUNCTION_PASS("callsite-splitting", CallSiteSplittingPass())
[PM] Port ConstantHoisting to the new Pass Manager Differential Revision: http://reviews.llvm.org/D21945 llvm-svn: 274411
2016-07-02 02:16:47 +02:00
FUNCTION_PASS("consthoist", ConstantHoistingPass())
[NewPM] Port ConstraintElimination to the new pass manager If -enable-constraint-elimination is specified, add it to the -O2/-O3 pipeline. (-O1 uses a separate function now.) Reviewed By: fhahn, aeubanks Differential Revision: https://reviews.llvm.org/D88365
2020-09-27 20:12:13 +02:00
FUNCTION_PASS("constraint-elimination", ConstraintEliminationPass())
[PGO] Control Height Reduction Summary: Control height reduction merges conditional blocks of code and reduces the number of conditional branches in the hot path based on profiles. if (hot_cond1) { // Likely true. do_stg_hot1(); } if (hot_cond2) { // Likely true. do_stg_hot2(); } -> if (hot_cond1 && hot_cond2) { // Hot path. do_stg_hot1(); do_stg_hot2(); } else { // Cold path. if (hot_cond1) { do_stg_hot1(); } if (hot_cond2) { do_stg_hot2(); } } This speeds up some internal benchmarks up to ~30%. Reviewers: davidxl Reviewed By: davidxl Subscribers: xbolva00, dmgreen, mehdi_amini, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D50591 llvm-svn: 341386
2018-09-04 19:19:13 +02:00
FUNCTION_PASS("chr", ControlHeightReductionPass())
[Coroutines][1/6] New pass manager: coro-early Summary: The first in a series of patches that ports the LLVM coroutines passes to the new pass manager infrastructure. This patch implements 'coro-early'. NB: All coroutines passes begin by checking that coroutine intrinsics are declared within the LLVM IR module they're operating on. To do so, they call `coro::declaresIntrinsics`. The next 3 patches in this series, which add new pass manager implementations of the 'coro-split', 'coro-elide', and 'coro-cleanup' passes, use a similar pattern as the one used here: a static function is shared across both old and new passes to detect if relevant coroutine intrinsics are delcared. To make this pattern easier to read, this patch adds `const` keywords to the parameters of `coro::declaresIntrinsics`. Reviewers: GorNishanov, lewissbaker, junparser, chandlerc, deadalnix, wenlei Reviewed By: wenlei Subscribers: ychen, wenlei, EricWF, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71898
2019-12-26 14:00:00 +01:00
FUNCTION_PASS("coro-early", CoroEarlyPass())
Re-land new pass manager coro-split and coro-elide This re-applies patches https://reviews.llvm.org/D71899 and https://reviews.llvm.org/D71900, which were reverted in https://reviews.llvm.org/rG11053a1cc61 and https://reviews.llvm.org/rGe999aa38d16. The underlying problem that caused two buildbots to fail with these patches is explained in https://reviews.llvm.org/rG26f356350bd -- older compliers disagree with the order in which the left- and right-hand side of an assignment in LazyCallGraph ought to be evaluated, which caused an assertion in SmallVector::operator[] to fire when the test suite was run.
2020-02-18 22:29:13 +01:00
FUNCTION_PASS("coro-elide", CoroElidePass())
[Coroutines][4/6] New pass manager: coro-cleanup Summary: Depends on https://reviews.llvm.org/D71900. The fourth in a series of patches that ports the LLVM coroutines passes to the new pass manager infrastructure. This patch implements 'coro-cleanup'. No existing regression tests check the behavior of coro-cleanup on its own, so this patch adds one. (A test named 'coro-cleanup.ll' exists, but it relies on the entire coroutines pipeline being run. It's updated to test the new pass manager in the 5th patch of this series.) Reviewers: GorNishanov, lewissbaker, chandlerc, junparser, deadalnix, wenlei Reviewed By: wenlei Subscribers: wenlei, EricWF, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D71901
2019-12-26 14:00:00 +01:00
FUNCTION_PASS("coro-cleanup", CoroCleanupPass())
[PM] Port CorrelatedValuePropagation llvm-svn: 274705
2016-07-07 01:26:29 +02:00
FUNCTION_PASS("correlated-propagation", CorrelatedValuePropagationPass())
PM: Port DCE to the new pass manager 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
2016-04-22 21:40:41 +02:00
FUNCTION_PASS("dce", DCEPass())
Add jump-threading optimization for deterministic finite automata The current JumpThreading pass does not jump thread loops since it can result in irreducible control flow that harms other optimizations. This prevents switch statements inside a loop from being optimized to use unconditional branches. This code pattern occurs in the core_state_transition function of Coremark. The state machine can be implemented manually with goto statements resulting in a large runtime improvement, and this transform makes the switch implementation match the goto version in performance. This patch specifically targets switch statements inside a loop that have the opportunity to be threaded. Once it identifies an opportunity, it creates new paths that branch directly to the correct code block. For example, the left CFG could be transformed to the right CFG: ``` sw.bb sw.bb / | \ / | \ case1 case2 case3 case1 case2 case3 \ | / / | \ latch.bb latch.2 latch.3 latch.1 br sw.bb / | \ sw.bb.2 sw.bb.3 sw.bb.1 br case2 br case3 br case1 ``` Co-author: Justin Kreiner @jkreiner Co-author: Ehsan Amiri @amehsan Reviewed By: SjoerdMeijer Differential Revision: https://reviews.llvm.org/D99205
2021-07-27 20:26:49 +02:00
FUNCTION_PASS("dfa-jump-threading", DFAJumpThreadingPass())
[DivRempairs] add a pass to optimize div/rem pairs (PR31028) This is intended to be a superset of the functionality from D31037 (EarlyCSE) but implemented as an independent pass, so there's no stretching of scope and feature creep for an existing pass. I also proposed a weaker version of this for SimplifyCFG in D30910. And I initially had almost this same functionality as an addition to CGP in the motivating example of PR31028: https://bugs.llvm.org/show_bug.cgi?id=31028 The advantage of positioning this ahead of SimplifyCFG in the pass pipeline is that it can allow more flattening. But it needs to be after passes (InstCombine) that could sink a div/rem and undo the hoisting that is done here. Decomposing remainder may allow removing some code from the backend (PPC and possibly others). Differential Revision: https://reviews.llvm.org/D37121 llvm-svn: 312862
2017-09-09 15:38:18 +02:00
FUNCTION_PASS("div-rem-pairs", DivRemPairsPass())
[PM] Port DSE to the new pass manager Patch by JakeVanAdrighem. Thanks! llvm-svn: 269847
2016-05-17 23:38:13 +02:00
FUNCTION_PASS("dse", DSEPass())
Revert "Extend CFGPrinter and CallPrinter with Heat Colors" This reverts r335996 which broke graph printing in Polly. llvm-svn: 336000
2018-06-29 19:48:58 +02:00
FUNCTION_PASS("dot-cfg", CFGPrinterPass())
FUNCTION_PASS("dot-cfg-only", CFGOnlyPrinterPass())
[EarlyCSE] Optionally use MemorySSA. NFC. Summary: Use MemorySSA, if requested, to do less conservative memory dependency checking. This change doesn't enable the MemorySSA enhanced EarlyCSE in the default pipelines, so should be NFC. Reviewers: dberlin, sanjoy, reames, majnemer Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D19821 llvm-svn: 280279
2016-08-31 21:24:10 +02:00
FUNCTION_PASS("early-cse", EarlyCSEPass(/*UseMemorySSA=*/false))
FUNCTION_PASS("early-cse-memssa", EarlyCSEPass(/*UseMemorySSA=*/true))
Rename CountingFunctionInserter and use for both mcount and cygprofile calls, before and after inlining Clang implements the -finstrument-functions flag inherited from GCC, which inserts calls to __cyg_profile_func_{enter,exit} on function entry and exit. This is useful for getting a trace of how the functions in a program are executed. Normally, the calls remain even if a function is inlined into another function, but it is useful to be able to turn this off for users who are interested in a lower-level trace, i.e. one that reflects what functions are called post-inlining. (We use this to generate link order files for Chromium.) LLVM already has a pass for inserting similar instrumentation calls to mcount(), which it does after inlining. This patch renames and extends that pass to handle calls both to mcount and the cygprofile functions, before and/or after inlining as controlled by function attributes. Differential Revision: https://reviews.llvm.org/D39287 llvm-svn: 318195
2017-11-14 22:09:45 +01:00
FUNCTION_PASS("ee-instrument", EntryExitInstrumenterPass(/*PostInlining=*/false))
[FixIrreducible][NewPM] Port -fix-irreducible to NPM In the NPM, a pass cannot depend on another non-analysis pass. So pin the test that tests that -lowerswitch is run automatically to legacy PM. Reviewed By: sameerds Differential Revision: https://reviews.llvm.org/D89051
2020-10-08 17:53:00 +02:00
FUNCTION_PASS("fix-irreducible", FixIrreduciblePass())
Introduce llvm.experimental.widenable_condition intrinsic This patch introduces a new instinsic `@llvm.experimental.widenable_condition` that allows explicit representation for guards. It is an alternative to using `@llvm.experimental.guard` intrinsic that does not contain implicit control flow. We keep finding places where `@llvm.experimental.guard` is not supported or treated too conservatively, and there are 2 reasons to that: - `@llvm.experimental.guard` has memory write side effect to model implicit control flow, and this sometimes confuses passes and analyzes that work with memory; - Not all passes and analysis are aware of the semantics of guards. These passes treat them as regular throwing call and have no idea that the condition of guard may be used to prove something. One well-known place which had caused us troubles in the past is explicit loop iteration count calculation in SCEV. Another example is new loop unswitching which is not aware of guards. Whenever a new pass appears, we potentially have this problem there. Rather than go and fix all these places (and commit to keep track of them and add support in future), it seems more reasonable to leverage the existing optimizer's logic as much as possible. The only significant difference between guards and regular explicit branches is that guard's condition can be widened. It means that a guard contains (explicitly or implicitly) a `deopt` block successor, and it is always legal to go there no matter what the guard condition is. The other successor is a guarded block, and it is only legal to go there if the condition is true. This patch introduces a new explicit form of guards alternative to `@llvm.experimental.guard` intrinsic. Now a widenable guard can be represented in the CFG explicitly like this: %widenable_condition = call i1 @llvm.experimental.widenable.condition() %new_condition = and i1 %cond, %widenable_condition br i1 %new_condition, label %guarded, label %deopt guarded: ; Guarded instructions deopt: call type @llvm.experimental.deoptimize(<args...>) [ "deopt"(<deopt_args...>) ] The new intrinsic `@llvm.experimental.widenable.condition` has semantics of an `undef`, but the intrinsic prevents the optimizer from folding it early. This form should exploit all optimization boons provided to `br` instuction, and it still can be widened by replacing the result of `@llvm.experimental.widenable.condition()` with `and` with any arbitrary boolean value (as long as the branch that is taken when it is `false` has a deopt and has no side-effects). For more motivation, please check llvm-dev discussion "[llvm-dev] Giving up using implicit control flow in guards". This patch introduces this new intrinsic with respective LangRef changes and a pass that converts old-style guards (expressed as intrinsics) into the new form. The naming discussion is still ungoing. Merging this to unblock further items. We can later change the name of this intrinsic. Reviewed By: reames, fedor.sergeev, sanjoy Differential Revision: https://reviews.llvm.org/D51207 llvm-svn: 348593
2018-12-07 15:39:46 +01:00
FUNCTION_PASS("make-guards-explicit", MakeGuardsExplicitPass())
Rename CountingFunctionInserter and use for both mcount and cygprofile calls, before and after inlining Clang implements the -finstrument-functions flag inherited from GCC, which inserts calls to __cyg_profile_func_{enter,exit} on function entry and exit. This is useful for getting a trace of how the functions in a program are executed. Normally, the calls remain even if a function is inlined into another function, but it is useful to be able to turn this off for users who are interested in a lower-level trace, i.e. one that reflects what functions are called post-inlining. (We use this to generate link order files for Chromium.) LLVM already has a pass for inserting similar instrumentation calls to mcount(), which it does after inlining. This patch renames and extends that pass to handle calls both to mcount and the cygprofile functions, before and/or after inlining as controlled by function attributes. Differential Revision: https://reviews.llvm.org/D39287 llvm-svn: 318195
2017-11-14 22:09:45 +01:00
FUNCTION_PASS("post-inline-ee-instrument", EntryExitInstrumenterPass(/*PostInlining=*/true))
code hoisting pass based on GVN This pass hoists duplicated computations in the program. The primary goal of gvn-hoist is to reduce the size of functions before inline heuristics to reduce the total cost of function inlining. Pass written by Sebastian Pop, Aditya Kumar, Xiaoyu Hu, and Brian Rzycki. Important algorithmic contributions by Daniel Berlin under the form of reviews. Differential Revision: http://reviews.llvm.org/D19338 llvm-svn: 275561
2016-07-15 15:45:20 +02:00
FUNCTION_PASS("gvn-hoist", GVNHoistPass())
[GVNSink][NewPM] Add GVNSinkPass to PassRegistry.def
2020-09-22 17:20:11 +02:00
FUNCTION_PASS("gvn-sink", GVNSinkPass())
Reland [docs][NewPM] Add docs for writing NPM passes As to not conflict with the legacy PM example passes under llvm/lib/Transforms/Hello, this is under HelloNew. This makes the CMakeLists.txt and general directory structure less confusing for people following the example. Much of the doc structure was taken from WritinAnLLVMPass.rst. This adds a HelloWorld pass which simply prints out each function name. More will follow after this, e.g. passes over different units of IR, analyses. https://llvm.org/docs/WritingAnLLVMPass.html contains a lot more. Relanded with missing "Support" dependency in LLVMBuild.txt. Reviewed By: ychen, asbirlea Differential Revision: https://reviews.llvm.org/D86979
2020-09-01 03:36:11 +02:00
FUNCTION_PASS("helloworld", HelloWorldPass())
[NewPM] Port infer-address-spaces And add it to the AMDGPU opt pipeline. Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D93880
2020-12-28 22:07:46 +01:00
FUNCTION_PASS("infer-address-spaces", InferAddressSpacesPass())
[PM] Port instcombine to the new pass manager! This is exciting as this is a much more involved port. This is a complex, existing transformation pass. All of the core logic is shared between both old and new pass managers. Only the access to the analyses is separate because the actual techniques are separate. This also uses a bunch of different and interesting analyses and is the first time where we need to use an analysis across an IR layer. This also paves the way to expose instcombine utility functions. I've got a static function that implements the core pass logic over a function which might be mildly interesting, but more interesting is likely exposing a routine which just uses instructions *already in* the worklist and combines until empty. I've switched one of my favorite instcombine tests to run with both as well to make sure this keeps working. llvm-svn: 226987
2015-01-24 05:19:17 +01:00
FUNCTION_PASS("instcombine", InstCombinePass())
[NFC] Port InstCount pass to new pass manager
2020-07-17 13:30:51 +02:00
FUNCTION_PASS("instcount", InstCountPass())
[instsimplify] Move the instsimplify pass to use more obvious file names and diretory. Also cleans up all the associated naming to be consistent and removes the public access to the pass ID which was unused in LLVM. Also runs clang-format over parts that changed, which generally cleans up a bunch of formatting. This is in preparation for doing some internal cleanups to the pass. Differential Revision: https://reviews.llvm.org/D47352 llvm-svn: 336028
2018-06-30 01:36:03 +02:00
FUNCTION_PASS("instsimplify", InstSimplifyPass())
[PM] Introduce a utility pass that preserves no analyses. Use this to test that path of invalidation. This test actually shows redundant invalidation here that is really bad. I'm going to work on fixing that next, but wanted to commit the test harness now that its all working. llvm-svn: 225257
2015-01-06 10:06:35 +01:00
FUNCTION_PASS("invalidate<all>", InvalidateAllAnalysesPass())
[IRCE] Make IRCE a Function pass. Summary: Make InductiveRangeCheckElimination a FunctionPass. Reviewers: reames, mkazantsev Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D73592
2020-01-27 22:33:34 +01:00
FUNCTION_PASS("irce", IRCEPass())
[PM] Port float2int to the new pass manager Differential Revision: http://reviews.llvm.org/D21704 llvm-svn: 273747
2016-06-25 01:32:02 +02:00
FUNCTION_PASS("float2int", Float2IntPass())
[PM] Sink the no-op pass parsing logic into the .def-based registry to simplify things. This will become more important as I add no-op analyses that want to re-use the logic we already have for analyses in the registry. For now, no functionality changed. llvm-svn: 225238
2015-01-06 03:37:55 +01:00
FUNCTION_PASS("no-op-function", NoOpFunctionPass())
Conditionally eliminate library calls where the result value is not used Summary: This pass shrink-wraps a condition to some library calls where the call result is not used. For example: sqrt(val); is transformed to if (val < 0) sqrt(val); Even if the result of library call is not being used, the compiler cannot safely delete the call because the function can set errno on error conditions. Note in many functions, the error condition solely depends on the incoming parameter. In this optimization, we can generate the condition can lead to the errno to shrink-wrap the call. Since the chances of hitting the error condition is low, the runtime call is effectively eliminated. These partially dead calls are usually results of C++ abstraction penalty exposed by inlining. This optimization hits 108 times in 19 C/C++ programs in SPEC2006. Reviewers: hfinkel, mehdi_amini, davidxl Subscribers: modocache, mgorny, mehdi_amini, xur, llvm-commits, beanz Differential Revision: https://reviews.llvm.org/D24414 llvm-svn: 284542
2016-10-18 23:36:27 +02:00
FUNCTION_PASS("libcalls-shrinkwrap", LibCallsShrinkWrapPass())
[NewPM][Lint] Port -lint to NewPM This also changes -lint from an analysis to a pass. It's similar to -verify, and that is a normal pass, and lives in llvm/IR. Reviewed By: ychen Differential Revision: https://reviews.llvm.org/D87057
2020-09-03 06:54:27 +02:00
FUNCTION_PASS("lint", LintPass())
[SVFS] Inject TLI Mappings in VFABI attribute. This patch introduces a function pass to inject the scalar-to-vector mappings stored in the TargetLIbraryInfo (TLI) into the Vector Function ABI (VFABI) variants attribute. The test is testing the injection for three vector libraries supported by the TLI (Accelerate, SVML, MASSV). The pass does not change any of the analysis associated to the function. Differential Revision: https://reviews.llvm.org/D70107
2019-11-11 20:42:18 +01:00
FUNCTION_PASS("inject-tli-mappings", InjectTLIMappings())
Port -instnamer to NPM Some clang tests use this. Reviewed By: akhuang Differential Revision: https://reviews.llvm.org/D89931
2020-10-22 07:55:34 +02:00
FUNCTION_PASS("instnamer", InstructionNamerPass())
[PM] Port LowerAtomic to the new pass manager. llvm-svn: 269511
2016-05-14 00:52:35 +02:00
FUNCTION_PASS("loweratomic", LowerAtomicPass())
[PM] Port LowerExpectIntrinsic to the new pass manager. This just lifts the logic into a static helper function, sinks the legacy pass to be a trivial wrapper of that helper fuction, and adds a trivial wrapper for the new PM as well. Not much to see here. I switched a test case to run in both modes, but we have to strip the dead prototypes separately as that pass isn't in the new pass manager (yet). llvm-svn: 226999
2015-01-24 12:13:02 +01:00
FUNCTION_PASS("lower-expect", LowerExpectIntrinsicPass())
[PM] Port LowerGuardIntrinsic to the new PM. llvm-svn: 277057
2016-07-29 00:08:41 +02:00
FUNCTION_PASS("lower-guard-intrinsic", LowerGuardIntrinsicPass())
Reapply r374743 with a fix for the ocaml binding Add a pass to lower is.constant and objectsize intrinsics This pass lowers is.constant and objectsize intrinsics not simplified by earlier constant folding, i.e. if the object given is not constant or if not using the optimized pass chain. The result is recursively simplified and constant conditionals are pruned, so that dead blocks are removed even for -O0. This allows inline asm blocks with operand constraints to work all the time. The new pass replaces the existing lowering in the codegen-prepare pass and fallbacks in SDAG/GlobalISEL and FastISel. The latter now assert on the intrinsics. Differential Revision: https://reviews.llvm.org/D65280 llvm-svn: 374784
2019-10-14 18:15:14 +02:00
FUNCTION_PASS("lower-constant-intrinsics", LowerConstantIntrinsicsPass())
[Matrix] Add first set of matrix intrinsics and initial lowering pass. This is the first patch adding an initial set of matrix intrinsics and a corresponding lowering pass. This has been discussed on llvm-dev: http://lists.llvm.org/pipermail/llvm-dev/2019-October/136240.html The first patch introduces four new intrinsics (transpose, multiply, columnwise load and store) and a LowerMatrixIntrinsics pass, that lowers those intrinsics to vector operations. Matrixes are embedded in a 'flat' vector (e.g. a 4 x 4 float matrix embedded in a <16 x float> vector) and the intrinsics take the dimension information as parameters. Those parameters need to be ConstantInt. For the memory layout, we initially assume column-major, but in the RFC we also described how to extend the intrinsics to support row-major as well. For the initial lowering, we split the input of the intrinsics into a set of column vectors, transform those column vectors and concatenate the result columns to a flat result vector. This allows us to lower the intrinsics without any shape propagation, as mentioned in the RFC. In follow-up patches, we plan to submit the following improvements: * Shape propagation to eliminate the embedding/splitting for each intrinsic. * Fused & tiled lowering of multiply and other operations. * Optimization remarks highlighting matrix expressions and costs. * Generate loops for operations on large matrixes. * More general block processing for operation on large vectors, exploiting shape information. We would like to add dedicated transpose, columnwise load and store intrinsics, even though they are not strictly necessary. For example, we could instead emit a large shufflevector instruction instead of the transpose. But we expect that to (1) become unwieldy for larger matrixes (even for 16x16 matrixes, the resulting shufflevector masks would be huge), (2) risk instcombine making small changes, causing us to fail to detect the transpose, preventing better lowerings For the load/store, we are additionally planning on exploiting the intrinsics for better alias analysis. Reviewers: anemet, Gerolf, reames, hfinkel, andrew.w.kaylor, efriedma, rengolin Reviewed By: anemet Differential Revision: https://reviews.llvm.org/D70456
2019-12-12 16:27:28 +01:00
FUNCTION_PASS("lower-matrix-intrinsics", LowerMatrixIntrinsicsPass())
Port -lower-matrix-intrinsics-minimal to NPM This reuses the existing lower-matrix-intrinsics pass rather than going the legacy pass route of creating a new pass. Use this new variant in the NPM -O0 pipeline. Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D91811
2020-11-18 08:09:20 +01:00
FUNCTION_PASS("lower-matrix-intrinsics-minimal", LowerMatrixIntrinsicsPass(true))
Default lowering for experimental.widenable.condition Introduces a pass that provides default lowering strategy for the `experimental.widenable.condition` intrinsic, replacing all its uses with `i1 true`. Differential Revision: https://reviews.llvm.org/D56096 Reviewed By: reames llvm-svn: 352739
2019-01-31 10:10:17 +01:00
FUNCTION_PASS("lower-widenable-condition", LowerWidenableConditionPass())
New pass: guard widening Summary: Implement guard widening in LLVM. Description from GuardWidening.cpp: The semantics of the `@llvm.experimental.guard` intrinsic lets LLVM transform it so that it fails more often that it did before the transform. This optimization is called "widening" and can be used hoist and common runtime checks in situations like these: ``` %cmp0 = 7 u< Length call @llvm.experimental.guard(i1 %cmp0) [ "deopt"(...) ] call @unknown_side_effects() %cmp1 = 9 u< Length call @llvm.experimental.guard(i1 %cmp1) [ "deopt"(...) ] ... ``` to ``` %cmp0 = 9 u< Length call @llvm.experimental.guard(i1 %cmp0) [ "deopt"(...) ] call @unknown_side_effects() ... ``` If `%cmp0` is false, `@llvm.experimental.guard` will "deoptimize" back to a generic implementation of the same function, which will have the correct semantics from that point onward. It is always _legal_ to deoptimize (so replacing `%cmp0` with false is "correct"), though it may not always be profitable to do so. NB! This pass is a work in progress. It hasn't been tuned to be "production ready" yet. It is known to have quadriatic running time and will not scale to large numbers of guards Reviewers: reames, atrick, bogner, apilipenko, nlewycky Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D20143 llvm-svn: 269997
2016-05-19 00:55:34 +02:00
FUNCTION_PASS("guard-widening", GuardWideningPass())
[PM] Port LoadStoreVectorizer to the new pass manager. Differential Revision: https://reviews.llvm.org/D54848 llvm-svn: 348570
2018-12-07 09:23:37 +01:00
FUNCTION_PASS("load-store-vectorizer", LoadStoreVectorizerPass())
[PM] Port LoopSimplify to the new pass manager. While here move simplifyLoop() function to the new header, as suggested by Chandler in the review. Differential Revision: http://reviews.llvm.org/D21404 llvm-svn: 274959
2016-07-09 05:03:01 +02:00
FUNCTION_PASS("loop-simplify", LoopSimplifyPass())
[PM] Port LoopSink to the new pass manager. 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
2017-01-20 09:42:19 +01:00
FUNCTION_PASS("loop-sink", LoopSinkPass())
[PM] Port LowerInvoke to the new pass manager llvm-svn: 278531
2016-08-12 19:28:27 +02:00
FUNCTION_PASS("lowerinvoke", LowerInvokePass())
[LowerSwitch][NewPM] Port lowerswitch to NPM Reviewed By: ychen Differential Revision: https://reviews.llvm.org/D87726
2020-09-16 00:02:23 +02:00
FUNCTION_PASS("lowerswitch", LowerSwitchPass())
[PM] Port Mem2Reg to the new pass manager. llvm-svn: 272630
2016-06-14 05:22:22 +02:00
FUNCTION_PASS("mem2reg", PromotePass())
[PM] Port MemCpyOpt to the new PM. The need for all these Lookup* functions is just because of calls to getAnalysis inside methods (i.e. not at the top level) of the runOnFunction method. They should be straightforward to clean up when the old PM is gone. llvm-svn: 272615
2016-06-14 04:44:55 +02:00
FUNCTION_PASS("memcpyopt", MemCpyOptPass())
[MergeICmps] Make the pass compatible with the new pass manager. Reviewers: gchatelet, spatel Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D62287 llvm-svn: 361490
2019-05-23 14:35:26 +02:00
FUNCTION_PASS("mergeicmps", MergeICmpsPass())
[NPM] Port -mergereturn to NPM Reviewed By: aeubanks Differential Revision: https://reviews.llvm.org/D89781
2020-10-20 19:32:28 +02:00
FUNCTION_PASS("mergereturn", UnifyFunctionExitNodesPass())
[PM] Port NaryReassociate to the new PM Differential Revision: https://reviews.llvm.org/D22648 llvm-svn: 276349
2016-07-22 00:28:52 +02:00
FUNCTION_PASS("nary-reassociate", NaryReassociatePass())
[NewGVN] Add the pass to PassRegistry.def. We need to hook up here to get it working with the new PM. Add a test while here (and remove a typo). llvm-svn: 290350
2016-12-22 17:35:02 +01:00
FUNCTION_PASS("newgvn", NewGVNPass())
Bring back "[PM] Port JumpThreading to the new PM" with a fix This reverts commit r272603 and adds a fix. Big thanks to Davide for pointing me at r216244 which gives some insight into how to fix this VS2013 issue. VS2013 can't synthesize a move constructor. So the fix here is to add one explicitly to the JumpThreadingPass class. llvm-svn: 272607
2016-06-14 02:51:09 +02:00
FUNCTION_PASS("jump-threading", JumpThreadingPass())
[PM] Port PartiallyInlineLibCalls to the new pass manager. llvm-svn: 270798
2016-05-26 01:38:53 +02:00
FUNCTION_PASS("partially-inline-libcalls", PartiallyInlineLibCallsPass())
[PM] Port LCSSA to the new PM. Differential Revision: http://reviews.llvm.org/D21090 llvm-svn: 272294
2016-06-09 21:44:46 +02:00
FUNCTION_PASS("lcssa", LCSSAPass())
[PM] Port LoopDataPrefetch to new pass manager Summary: Refactor the existing support into a LoopDataPrefetch implementation class and a LoopDataPrefetchLegacyPass class that invokes it. Add a new LoopDataPrefetchPass for the new pass manager that utilizes the LoopDataPrefetch implementation class. Reviewers: mehdi_amini Subscribers: sanjoy, mzolotukhin, nemanjai, llvm-commits Differential Revision: https://reviews.llvm.org/D23483 llvm-svn: 278591
2016-08-13 06:11:27 +02:00
FUNCTION_PASS("loop-data-prefetch", LoopDataPrefetchPass())
[PM] Port LoopLoadElimination to the new pass manager and wire it into 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
2017-01-27 02:32:26 +01:00
FUNCTION_PASS("loop-load-elim", LoopLoadEliminationPass())
[NewPM][LoopFusion] Rename loop-fuse -> loop-fusion The legacy pass name is "loop-fusion". Fixes most tests under Transforms/LoopFusion under NPM. Reviewed By: Whitney Differential Revision: https://reviews.llvm.org/D83066
2020-07-07 19:42:33 +02:00
FUNCTION_PASS("loop-fusion", LoopFusePass())
[LoopDist] Port to new PM Summary: The direct motivation for the port is to ensure that the OptRemarkEmitter tests work with the new PM. This remains a function pass because we not only create multiple loops but could also version the original loop. In the test I need to invoke opt with -passes='require<aa>,loop-distribute'. LoopDistribute does not directly depend on AA however LAA does. LAA uses getCachedResult so I *think* we need manually pull in 'aa'. Reviewers: davidxl, silvas Subscribers: sanjoy, llvm-commits, mzolotukhin Differential Revision: https://reviews.llvm.org/D22437 llvm-svn: 275811
2016-07-18 18:29:27 +02:00
FUNCTION_PASS("loop-distribute", LoopDistributePass())
[NewPM][LoopVersioning] Port LoopVersioning to NPM Reviewed By: ychen, fhahn Differential Revision: https://reviews.llvm.org/D85063
2020-08-01 02:30:30 +02:00
FUNCTION_PASS("loop-versioning", LoopVersioningPass())
[NewPM] Run ObjC ARC passes Match the legacy PM in running various ObjC ARC passes. This requires making some module passes into function passes. These were initially ported as module passes since they add function declarations (e.g. https://reviews.llvm.org/D86178), but that's still up for debate and other passes do so. Reviewed By: ahatanak Differential Revision: https://reviews.llvm.org/D93743
2020-12-23 06:41:25 +01:00
FUNCTION_PASS("objc-arc", ObjCARCOptPass())
FUNCTION_PASS("objc-arc-contract", ObjCARCContractPass())
Port -objc-arc-expand to NPM Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D90182
2020-10-26 19:59:23 +01:00
FUNCTION_PASS("objc-arc-expand", ObjCARCExpandPass())
[PGO] Memory intrinsic calls optimization based on profiled size This patch optimizes two memory intrinsic operations: memset and memcpy based on the profiled size of the operation. The high level transformation is like: mem_op(..., size) ==> switch (size) { case s1: mem_op(..., s1); goto merge_bb; case s2: mem_op(..., s2); goto merge_bb; ... default: mem_op(..., size); goto merge_bb; } merge_bb: Differential Revision: http://reviews.llvm.org/D28966 llvm-svn: 299446
2017-04-04 18:42:20 +02:00
FUNCTION_PASS("pgo-memop-opt", PGOMemOPSizeOpt())
[PM] Add a nice low-tech registry of passes as a boring macro expansion file. This will make it easy to scale up the number of passes supported. Currently, it just supports the function and module transformation passes that were already supported in the opt tool explicitly. llvm-svn: 206737
2014-04-21 10:08:50 +02:00
FUNCTION_PASS("print", PrintFunctionPass(dbgs()))
Revert @llvm.assume with operator bundles (r289755-r289757) This creates non-linear behavior in the inliner (see more details in r289755's commit thread). llvm-svn: 290086
2016-12-19 09:22:17 +01:00
FUNCTION_PASS("print<assumptions>", AssumptionPrinterPass(dbgs()))
[PM] port Branch Frequency Analaysis pass to new PM llvm-svn: 268687
2016-05-05 23:13:27 +02:00
FUNCTION_PASS("print<block-freq>", BlockFrequencyPrinterPass(dbgs()))
[PM] Port Branch Probability Analysis pass to the new pass manager. Differential Revision: http://reviews.llvm.org/D19839 llvm-svn: 268601
2016-05-05 04:59:57 +02:00
FUNCTION_PASS("print<branch-prob>", BranchProbabilityPrinterPass(dbgs()))
[DA][NewPM] Add a printerpass and port the testsuite The new-pm version of DA is untested. Testing requires a printer, so add that and use it in the existing DA tests. Differential Revision: https://reviews.llvm.org/D56386 llvm-svn: 350624
2019-01-08 15:06:58 +01:00
FUNCTION_PASS("print<da>", DependenceAnalysisPrinterPass(dbgs()))
[NewPM] Introduce (GPU)DivergenceAnalysis in the new pass manager The GPUDivergenceAnalysis is now renamed to just "DivergenceAnalysis" since there is no conflict with LegacyDivergenceAnalysis. In the legacy PM, this analysis can only be used through the legacy DA serving as a wrapper. It is now made available as a pass in the new PM, and has no relation with the legacy DA. The new DA currently cannot handle irreducible control flow; its presence can cause the analysis to run indefinitely. The analysis is now modified to detect this and report all instructions in the function as divergent. This is super conservative, but allows the analysis to be used without hanging the compiler. Reviewed By: aeubanks Differential Revision: https://reviews.llvm.org/D96615
2021-02-16 05:56:45 +01:00
FUNCTION_PASS("print<divergence>", DivergenceAnalysisPrinterPass(dbgs()))
[PM] Port domtree to the new pass manager (at last). This adds the domtree analysis to the new pass manager. The analysis returns the same DominatorTree result entity used by the old pass manager and essentially all of the code is shared. We just have different boilerplate for running and printing the analysis. I've converted one test to run in both modes just to make sure this is exercised while both are live in the tree. llvm-svn: 225969
2015-01-14 11:19:28 +01:00
FUNCTION_PASS("print<domtree>", DominatorTreePrinterPass(dbgs()))
Introduce analysis pass to compute PostDominators in the new pass manager. NFC Differential Revision: http://reviews.llvm.org/D17537 llvm-svn: 261902
2016-02-25 18:54:07 +01:00
FUNCTION_PASS("print<postdomtree>", PostDominatorTreePrinterPass(dbgs()))
[Delinearization][NewPM] Port delinearization to NPM Also make tests in Analysis/Delinearization work under NPM. Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D87741
2020-09-16 06:10:22 +02:00
FUNCTION_PASS("print<delinearization>", DelinearizationPrinterPass(dbgs()))
Port DemandedBits to the new pass manager. Differential Revision: http://reviews.llvm.org/D18679 llvm-svn: 266699
2016-04-19 01:55:01 +02:00
FUNCTION_PASS("print<demanded-bits>", DemandedBitsPrinterPass(dbgs()))
Introduce DominanceFrontierAnalysis to the new PassManager to compute DominanceFrontier. NFC Differential Revision: http://reviews.llvm.org/D17570 llvm-svn: 261903
2016-02-25 18:54:15 +01:00
FUNCTION_PASS("print<domfrontier>", DominanceFrontierPrinterPass(dbgs()))
Add a Printer to the FunctionPropertiesAnalysis A printer pass and a lit test case was added. Reviewed By: mtrofin Differential Revision: https://reviews.llvm.org/D82523
2020-07-23 20:56:56 +02:00
FUNCTION_PASS("print<func-properties>", FunctionPropertiesPrinterPass(dbgs()))
[InlineCost] InlineCostAnnotationWriterPass introduced This class allows to see the inliner's decisions for better optimization verifications and tests. To use, use flag "-passes="print<inline-cost>"". This is the second attempt to integrate the patch. The problem from the first try has been discussed and fixed in D82205. Reviewers: apilipenko, mtrofin, davidxl, fedor.sergeev Reviewed By: mtrofin Differential revision: https://reviews.llvm.org/D81743
2020-06-12 00:24:10 +02:00
FUNCTION_PASS("print<inline-cost>", InlineCostAnnotationPrinterPass(dbgs()))
[Passes] Add relative lookup table converter pass Lookup tables generate non PIC-friendly code, which requires dynamic relocation as described in: https://bugs.llvm.org/show_bug.cgi?id=45244 This patch adds a new pass that converts lookup tables to relative lookup tables to make them PIC-friendly. Differential Revision: https://reviews.llvm.org/D94355
2020-12-29 22:32:13 +01:00
FUNCTION_PASS("print<inliner-size-estimator>",
[llvm] Moved InlineSizeEstimatorAnalysis test to .ll Summary: Following guidance in https://llvm.org/docs/TestingGuide.html#testing-analysis Reviewers: mehdi_amini Subscribers: mgorny, hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D83918
2020-07-16 01:02:15 +02:00
InlineSizeEstimatorAnalysisPrinterPass(dbgs()))
[PM] Port LoopInfo to the new pass manager, adding both a LoopAnalysis pass and a LoopPrinterPass with the expected associated wiring. I've added a RUN line to the only test case (!!!) we have that actually prints loops. Everything seems to be working. This is somewhat exciting as this is the first analysis using another analysis to go in for the new pass manager. =D I also believe it is the last analysis necessary for porting instcombine, but of course I may yet discover more. llvm-svn: 226560
2015-01-20 11:58:50 +01:00
FUNCTION_PASS("print<loops>", LoopPrinterPass(dbgs()))
[MemorySSA] Port to new pass manager Add support for the new pass manager to MemorySSA pass. Change MemorySSA to be computed eagerly upon construction. Change MemorySSAWalker to be owned by the MemorySSA object that creates it. Reviewers: dberlin, george.burgess.iv Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D19664 llvm-svn: 271432
2016-06-01 23:30:40 +02:00
FUNCTION_PASS("print<memoryssa>", MemorySSAPrinterPass(dbgs()))
Add a PhiValuesAnalysis pass to calculate the underlying values of phis This pass is being added in order to make the information available to BasicAA, which can't do caching of this information itself, but possibly this information may be useful for other passes. Incorporates code based on Daniel Berlin's implementation of Tarjan's algorithm. Differential Revision: https://reviews.llvm.org/D47893 llvm-svn: 335857
2018-06-28 16:13:06 +02:00
FUNCTION_PASS("print<phi-values>", PhiValuesPrinterPass(dbgs()))
Introduce RegionInfoAnalysis, which compute Region Tree in the new PassManager. NFC Differential Revision: http://reviews.llvm.org/D17571 llvm-svn: 261904
2016-02-25 18:54:25 +01:00
FUNCTION_PASS("print<regions>", RegionInfoPrinterPass(dbgs()))
[PM] Port ScalarEvolution to the new pass manager. This change makes ScalarEvolution a stand-alone object and just produces one from a pass as needed. Making this work well requires making the object movable, using references instead of overwritten pointers in a number of places, and other refactorings. I've also wired it up to the new pass manager and added a RUN line to a test to exercise it under the new pass manager. This includes basic printing support much like with other analyses. But there is a big and somewhat scary change here. Prior to this patch ScalarEvolution was never *actually* invalidated!!! Re-running the pass just re-wired up the various other analyses and didn't remove any of the existing entries in the SCEV caches or clear out anything at all. This might seem OK as everything in SCEV that can uses ValueHandles to track updates to the values that serve as SCEV keys. However, this still means that as we ran SCEV over each function in the module, we kept accumulating more and more SCEVs into the cache. At the end, we would have a SCEV cache with every value that we ever needed a SCEV for in the entire module!!! Yowzers. The releaseMemory routine would dump all of this, but that isn't realy called during normal runs of the pipeline as far as I can see. To make matters worse, there *is* actually a key that we don't update with value handles -- there is a map keyed off of Loop*s. Because LoopInfo *does* release its memory from run to run, it is entirely possible to run SCEV over one function, then over another function, and then lookup a Loop* from the second function but find an entry inserted for the first function! Ouch. To make matters still worse, there are plenty of updates that *don't* trip a value handle. It seems incredibly unlikely that today GVN or another pass that invalidates SCEV can update values in *just* such a way that a subsequent run of SCEV will incorrectly find lookups in a cache, but it is theoretically possible and would be a nightmare to debug. With this refactoring, I've fixed all this by actually destroying and recreating the ScalarEvolution object from run to run. Technically, this could increase the amount of malloc traffic we see, but then again it is also technically correct. ;] I don't actually think we're suffering from tons of malloc traffic from SCEV because if we were, the fact that we never clear the memory would seem more likely to have come up as an actual problem before now. So, I've made the simple fix here. If in fact there are serious issues with too much allocation and deallocation, I can work on a clever fix that preserves the allocations (while clearing the data) between each run, but I'd prefer to do that kind of optimization with a test case / benchmark that shows why we need such cleverness (and that can test that we actually make it faster). It's possible that this will make some things faster by making the SCEV caches have higher locality (due to being significantly smaller) so until there is a clear benchmark, I think the simple change is best. Differential Revision: http://reviews.llvm.org/D12063 llvm-svn: 245193
2015-08-17 04:08:17 +02:00
FUNCTION_PASS("print<scalar-evolution>", ScalarEvolutionPrinterPass(dbgs()))
[stack-safety] Empty local passes for Stack Safety Local Analysis Reviewers: eugenis, vlad.tsyrklevich Subscribers: mgorny, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D54502 llvm-svn: 347602
2018-11-26 22:57:47 +01:00
FUNCTION_PASS("print<stack-safety-local>", StackSafetyPrinterPass(dbgs()))
Port print-must-be-executed-contexts and print-mustexecute to NPM Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D90207
2020-10-27 03:57:39 +01:00
// TODO: rename to print<foo> after NPM switch
[NewPM] Port -print-alias-sets to NPM Really it should be named print<alias-sets>, but for the sake of changing fewer tests, added a TODO to rename after NPM switch and test cleanup. Reviewed By: ychen Differential Revision: https://reviews.llvm.org/D87713
2020-09-15 04:01:38 +02:00
FUNCTION_PASS("print-alias-sets", AliasSetsPrinterPass(dbgs()))
[NewPM] Add PredicateInfoPrinterPass to PassRegistry.def Fixes tests under NPM in Transforms/Util/PredicateInfo.
2020-07-08 18:27:57 +02:00
FUNCTION_PASS("print-predicateinfo", PredicateInfoPrinterPass(dbgs()))
Port print-must-be-executed-contexts and print-mustexecute to NPM Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D90207
2020-10-27 03:57:39 +01:00
FUNCTION_PASS("print-mustexecute", MustExecutePrinterPass(dbgs()))
Port -print-memderefs to NPM There is lots of code duplication, but hopefully it won't matter soon. Reviewed By: ychen Differential Revision: https://reviews.llvm.org/D91683
2020-11-18 08:42:18 +01:00
FUNCTION_PASS("print-memderefs", MemDerefPrinterPass(dbgs()))
PM: Port Reassociate to the new pass manager llvm-svn: 267631
2016-04-27 01:39:29 +02:00
FUNCTION_PASS("reassociate", ReassociatePass())
[DCE] Port -redundant-dbg-inst-elim to NPM This is used to test RemoveRedundantDbgInstrs(), which is used by other passes. Reviewed By: ychen Differential Revision: https://reviews.llvm.org/D91477
2020-11-14 08:40:33 +01:00
FUNCTION_PASS("redundant-dbg-inst-elim", RedundantDbgInstEliminationPass())
[Reg2Mem] add support for the new pass manager This patch refactors the pass to accomodate the new pass manager boilerplate. Differential Revision: https://reviews.llvm.org/D91005
2020-11-05 20:03:08 +01:00
FUNCTION_PASS("reg2mem", RegToMemPass())
[ScalarizeMaskedMemIntrin] Add new PM support This patch adds new PM support for the pass and the pass can be now used during middle-end transforms. The old pass is remamed to ScalarizeMaskedMemIntrinLegacyPass. Reviewed-By: skatkov, aeubanks Differential Revision: https://reviews.llvm.org/D92743
2020-12-07 04:51:23 +01:00
FUNCTION_PASS("scalarize-masked-mem-intrin", ScalarizeMaskedMemIntrinPass())
[PM] Port Scalarizer to the new pass manager. Patch by: markus (Markus Lavin) Reviewers: chandlerc, fedor.sergeev Reviewed By: fedor.sergeev Subscribers: llvm-commits, Ka-Ka, bjope Differential Revision: https://reviews.llvm.org/D54695 llvm-svn: 347392
2018-11-21 15:00:17 +01:00
FUNCTION_PASS("scalarizer", ScalarizerPass())
[NewPM] Port -separate-const-offset-from-gep Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D91095
2020-11-09 20:40:49 +01:00
FUNCTION_PASS("separate-const-offset-from-gep", SeparateConstOffsetFromGEPPass())
[PM] Port per-function SCCP to the new pass manager. llvm-svn: 269937
2016-05-18 17:18:25 +02:00
FUNCTION_PASS("sccp", SCCPPass())
PM: Port SinkingPass to the new pass manager llvm-svn: 267199
2016-04-22 21:54:10 +02:00
FUNCTION_PASS("sink", SinkingPass())
[PM] Port SLPVectorizer to the new PM This uses the "runImpl" approach to share code with the old PM. Porting to the new PM meant abandoning the anonymous namespace enclosing most of SLPVectorizer.cpp which is a bit of a bummer (but not a big deal compared to having to pull the pass class into a header which the new PM requires since it calls the constructor directly). llvm-svn: 272766
2016-06-15 10:43:40 +02:00
FUNCTION_PASS("slp-vectorizer", SLPVectorizerPass())
[NPM] Port -slsr to NPM `-separate-const-offset-from-gep` has not yet be ported, so some tests are not updated. Reviewed By: aeubanks Differential Revision: https://reviews.llvm.org/D90149
2020-10-27 02:21:07 +01:00
FUNCTION_PASS("slsr", StraightLineStrengthReducePass())
[PM] Port SpeculativeExecution to the new PM Differential Revision: https://reviews.llvm.org/D23033 llvm-svn: 277393
2016-08-01 23:48:33 +02:00
FUNCTION_PASS("speculative-execution", SpeculativeExecutionPass())
[PM] Port SROA to the new pass manager. In some ways this is a very boring port to the new pass manager as there are no interesting analyses or dependencies or other oddities. However, this does introduce the first good example of a transformation pass with non-trivial state porting to the new pass manager. I've tried to carve out patterns here to replicate elsewhere, and would appreciate comments on whether folks like these patterns: - A common need in the new pass manager is to effectively lift the pass class and some of its state into a public header file. Prior to this, LLVM used anonymous namespaces to provide "module private" types and utilities, but that doesn't scale to cases where a public header file is needed and the new pass manager will exacerbate that. The pattern I've adopted here is to use the namespace-cased-name of the core pass (what would be a module if we had them) as a module-private namespace. Then utility and other code can be declared and defined in this namespace. At some point in the future, we could even have (conditionally compiled) code that used modules features when available to do the same basic thing. - I've split the actual pass run method in two in order to expose a private method usable by the old pass manager to wrap the new class with a minimum of duplicated code. I actually looked at a bunch of ways to automate or generate these, but they are all quite terrible IMO. The fundamental need is to extract the set of analyses which need to cross this interface boundary, and that will end up being too unpredictable to effectively encapsulate IMO. This is also a relatively small amount of boiler plate that will live a relatively short time, so I'm not too worried about the fact that it is boiler plate. The rest of the patch is totally boring but results in a massive diff (sorry). It just moves code around and removes or adds qualifiers to reflect the new name and nesting structure. Differential Revision: http://reviews.llvm.org/D12773 llvm-svn: 247501
2015-09-12 11:09:14 +02:00
FUNCTION_PASS("sroa", SROA())
Port StripGCRelocates pass to NPM Fixes one test under NPM Differential Revision: https://reviews.llvm.org/D88766
2020-10-03 01:31:57 +02:00
FUNCTION_PASS("strip-gc-relocates", StripGCRelocates())
[StructurizeCFG][NewPM] Port -structurizecfg to NPM This doesn't support -structurizecfg-skip-uniform-regions since that would require porting LegacyDivergenceAnalysis. The NPM doesn't support adding a non-analysis pass as a dependency of another, so I had to add -lowerswitch to some tests or pin them to the legacy PM. This is the only RegionPass in tree, so I simply copied the logic for finding all Regions from the legacy PM's RGManager into StructurizeCFG::run(). Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D89026
2020-10-08 07:07:30 +02:00
FUNCTION_PASS("structurizecfg", StructurizeCFGPass())
[PM] Port TailCallElim llvm-svn: 274708
2016-07-07 01:48:41 +02:00
FUNCTION_PASS("tailcallelim", TailCallElimPass())
[NPM] port -unify-loop-exits to NPM Reviewed By: aeubanks Differential Revision: https://reviews.llvm.org/D89774
2020-10-20 19:41:38 +02:00
FUNCTION_PASS("unify-loop-exits", UnifyLoopExitsPass())
[VectorCombine] new IR transform pass for partial vector ops We have several bug reports that could be characterized as "reducing scalarization", and this topic was also raised on llvm-dev recently: http://lists.llvm.org/pipermail/llvm-dev/2020-January/138157.html ...so I'm proposing that we deal with these patterns in a new, lightweight IR vector pass that runs before/after other vectorization passes. There are 4 alternate options that I can think of to deal with this kind of problem (and we've seen various attempts at all of these), but they all have flaws: InstCombine - can't happen without TTI, but we don't want target-specific folds there. SDAG - too late to assist other vectorization passes; TLI is not equipped for these kind of cost queries; limited to a single basic block. CGP - too late to assist other vectorization passes; would need to re-implement basic cleanups like CSE/instcombine. SLP - doesn't fit with existing transforms; limited to a single basic block. This initial patch/transform is based on existing code in AggressiveInstCombine: we walk backwards through the function looking for a pattern match. But we diverge from that cost-independent IR canonicalization pass by using TTI to decide if the vector alternative is profitable. We probably have at least 10 similar bug reports/patterns (binops, constants, inserts, cheap shuffles, etc) that would fit in this pass as follow-up enhancements. It's possible that we could iterate on a worklist to fix-point like InstCombine does, but it's safer to start with a most basic case and evolve from there, so I didn't try to do anything fancy with this initial implementation. Differential Revision: https://reviews.llvm.org/D73480
2020-02-09 16:04:41 +01:00
FUNCTION_PASS("vector-combine", VectorCombinePass())
[PM] Wire up support for explicitly running the verifier pass. The required functionality has been there for some time, but I never managed to actually wire it into the command line registry of passes. Let's do that. llvm-svn: 225144
2015-01-05 01:08:53 +01:00
FUNCTION_PASS("verify", VerifierPass())
[PM] Port domtree to the new pass manager (at last). This adds the domtree analysis to the new pass manager. The analysis returns the same DominatorTree result entity used by the old pass manager and essentially all of the code is shared. We just have different boilerplate for running and printing the analysis. I've converted one test to run in both modes just to make sure this is exercised while both are live in the tree. llvm-svn: 225969
2015-01-14 11:19:28 +01:00
FUNCTION_PASS("verify<domtree>", DominatorTreeVerifierPass())
[PM] Port LoopUnroll. We just set PreserveLCSSA to always true since we don't have an analogous method `mustPreserveAnalysisID(LCSSA)`. Also port LoopInfo verifier pass to test LoopUnrollPass. llvm-svn: 276063
2016-07-20 01:54:23 +02:00
FUNCTION_PASS("verify<loops>", LoopVerifierPass())
[MemorySSA] Port to new pass manager Add support for the new pass manager to MemorySSA pass. Change MemorySSA to be computed eagerly upon construction. Change MemorySSAWalker to be owned by the MemorySSA object that creates it. Reviewers: dberlin, george.burgess.iv Subscribers: mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D19664 llvm-svn: 271432
2016-06-01 23:30:40 +02:00
FUNCTION_PASS("verify<memoryssa>", MemorySSAVerifierPass())
Introduce RegionInfoAnalysis, which compute Region Tree in the new PassManager. NFC Differential Revision: http://reviews.llvm.org/D17571 llvm-svn: 261904
2016-02-25 18:54:25 +01:00
FUNCTION_PASS("verify<regions>", RegionInfoVerifierPass())
SafepointIRVerifier port to new Pass Manager Straightforward port of StatepointIRVerifier pass to new Pass Manager framework. Fix By: skatkov Reviewed By: fedor.sergeev Differential Revision: https://reviews.llvm.org/D59825 This is a re-land of r357147/r357148 with LLVM_ENABLE_MODULES build fixed. Adding IR/SafepointIRVerifier.h into its own module. llvm-svn: 357361
2019-03-31 12:15:39 +02:00
FUNCTION_PASS("verify<safepoint-ir>", SafepointIRVerifierPass())
[SCEV] Make SCEV verification available from command line with new PM New pass manager doesn't use verifyAnalysis, so currently there is no way to call SCEV verification from command line when new PM is used. This patch adds a pass that allows you to do that. Reviewers: reames, fhahn, sanjoy.google, nikic Reviewed By: fhahn Subscribers: hiraditya, javed.absar, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D70423
2019-11-19 08:16:39 +01:00
FUNCTION_PASS("verify<scalar-evolution>", ScalarEvolutionVerifierPass())
Revert "Extend CFGPrinter and CallPrinter with Heat Colors" This reverts r335996 which broke graph printing in Polly. llvm-svn: 336000
2018-06-29 19:48:58 +02:00
FUNCTION_PASS("view-cfg", CFGViewerPass())
FUNCTION_PASS("view-cfg-only", CFGOnlyViewerPass())
[Unroll/UnrollAndJam/Vectorizer/Distribute] Add followup loop attributes. When multiple loop transformation are defined in a loop's metadata, their order of execution is defined by the order of their respective passes in the pass pipeline. For instance, e.g. #pragma clang loop unroll_and_jam(enable) #pragma clang loop distribute(enable) is the same as #pragma clang loop distribute(enable) #pragma clang loop unroll_and_jam(enable) and will try to loop-distribute before Unroll-And-Jam because the LoopDistribute pass is scheduled after UnrollAndJam pass. UnrollAndJamPass only supports one inner loop, i.e. it will necessarily fail after loop distribution. It is not possible to specify another execution order. Also,t the order of passes in the pipeline is subject to change between versions of LLVM, optimization options and which pass manager is used. This patch adds 'followup' attributes to various loop transformation passes. These attributes define which attributes the resulting loop of a transformation should have. For instance, !0 = !{!0, !1, !2} !1 = !{!"llvm.loop.unroll_and_jam.enable"} !2 = !{!"llvm.loop.unroll_and_jam.followup_inner", !3} !3 = !{!"llvm.loop.distribute.enable"} defines a loop ID (!0) to be unrolled-and-jammed (!1) and then the attribute !3 to be added to the jammed inner loop, which contains the instruction to distribute the inner loop. Currently, in both pass managers, pass execution is in a fixed order and UnrollAndJamPass will not execute again after LoopDistribute. We hope to fix this in the future by allowing pass managers to run passes until a fixpoint is reached, use Polly to perform these transformations, or add a loop transformation pass which takes the order issue into account. For mandatory/forced transformations (e.g. by having been declared by #pragma omp simd), the user must be notified when a transformation could not be performed. It is not possible that the responsible pass emits such a warning because the transformation might be 'hidden' in a followup attribute when it is executed, or it is not present in the pipeline at all. For this reason, this patche introduces a WarnMissedTransformations pass, to warn about orphaned transformations. Since this changes the user-visible diagnostic message when a transformation is applied, two test cases in the clang repository need to be updated. To ensure that no other transformation is executed before the intended one, the attribute `llvm.loop.disable_nonforced` can be added which should disable transformation heuristics before the intended transformation is applied. E.g. it would be surprising if a loop is distributed before a #pragma unroll_and_jam is applied. With more supported code transformations (loop fusion, interchange, stripmining, offloading, etc.), transformations can be used as building blocks for more complex transformations (e.g. stripmining+stripmining+interchange -> tiling). Reviewed By: hfinkel, dmgreen Differential Revision: https://reviews.llvm.org/D49281 Differential Revision: https://reviews.llvm.org/D55288 llvm-svn: 348944
2018-12-12 18:32:52 +01:00
FUNCTION_PASS("transform-warning", WarnMissedTransformationsPass())
[NewPM] Second attempt at porting ASan This is the second attempt to port ASan to new PM after D52739. This takes the initialization requried by ASan from the Module by moving it into a separate class with it's own analysis that the new PM ASan can use. Changes: - Split AddressSanitizer into 2 passes: 1 for the instrumentation on the function, and 1 for the pass itself which creates an instance of the first during it's run. The same is done for AddressSanitizerModule. - Add new PM AddressSanitizer and AddressSanitizerModule. - Add legacy and new PM analyses for reading data needed to initialize ASan with. - Removed DominatorTree dependency from ASan since it was unused. - Move GlobalsMetadata and ShadowMapping out of anonymous namespace since the new PM analysis holds these 2 classes and will need to expose them. Differential Revision: https://reviews.llvm.org/D56470 llvm-svn: 353985
2019-02-13 23:22:48 +01:00
FUNCTION_PASS("asan", AddressSanitizerPass(false, false, false))
[NewPM] Setup Passes for KASan and KMSan While ASan and MSan passes were already ported to new PM, the kernel variants weren't setup in the pipeline which makes the KASan and KMSan tests in Clang fail. Differential Revision: https://reviews.llvm.org/D61664 llvm-svn: 360313
2019-05-09 08:09:35 +02:00
FUNCTION_PASS("kasan", AddressSanitizerPass(true, false, false))
[NewPM][MSan] Add Options Handling Summary: This patch enables passing options to msan via the passes pipeline, e.e., -passes=msan<recover;kernel;track-origins=4>. Reviewers: chandlerc, fedor.sergeev, leonardchan Subscribers: hiraditya, bollu, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57640 llvm-svn: 353090
2019-02-04 22:02:49 +01:00
FUNCTION_PASS("msan", MemorySanitizerPass({}))
[NewPM] Setup Passes for KASan and KMSan While ASan and MSan passes were already ported to new PM, the kernel variants weren't setup in the pipeline which makes the KASan and KMSan tests in Clang fail. Differential Revision: https://reviews.llvm.org/D61664 llvm-svn: 360313
2019-05-09 08:09:35 +02:00
FUNCTION_PASS("kmsan", MemorySanitizerPass({0, false, /*Kernel=*/true}))
[NewPM][TSan] Reiterate the TSan port Summary: Second iteration of D56433 which got reverted in rL350719. The problem in the previous version was that we dropped the thunk calling the tsan init function. The new version keeps the thunk which should appease dyld, but is not actually OK wrt. the current semantics of function passes. Hence, add a helper to insert the functions only on the first time. The helper allows hooking into the insertion to be able to append them to the global ctors list. Reviewers: chandlerc, vitalybuka, fedor.sergeev, leonardchan Subscribers: hiraditya, bollu, llvm-commits Differential Revision: https://reviews.llvm.org/D56538 llvm-svn: 351314
2019-01-16 10:28:01 +01:00
FUNCTION_PASS("tsan", ThreadSanitizerPass())
[MemProf] Rename HeapProfiler to MemProfiler for consistency This is consistent with the clang option added in 7ed8124d46f94601d5f1364becee9cee8538265e, and the comments on the runtime patch in D87120. Differential Revision: https://reviews.llvm.org/D87622
2020-09-14 18:12:13 +02:00
FUNCTION_PASS("memprof", MemProfilerPass())
[PM] Add a nice low-tech registry of passes as a boring macro expansion file. This will make it easy to scale up the number of passes supported. Currently, it just supports the function and module transformation passes that were already supported in the opt tool explicitly. llvm-svn: 206737
2014-04-21 10:08:50 +02:00
#undef FUNCTION_PASS
PM: Implement a basic loop pass manager 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
2016-02-25 08:23:08 +01:00
[LoopUnroll] add parsing for unroll parameters in -passes pipeline Allow to specify loop-unrolling with optional parameters explicitly spelled out in -passes pipeline specification. Introducing somewhat generic way of specifying parameters parsing via FUNCTION_PASS_PARAMETRIZED pass registration. Syntax of parametrized unroll pass name is as follows: 'unroll<' parameter-list '>' Where parameter-list is ';'-separate list of parameter names and optlevel optlevel: 'O[0-3]' parameter: { 'partial' | 'peeling' | 'runtime' | 'upperbound' } negated: 'no-' parameter Example: -passes=loop(unroll<O3;runtime;no-upperbound>) this invokes LoopUnrollPass configured with OptLevel=3, Runtime, no UpperBound, everything else by default. llvm-svn: 350808
2019-01-10 11:01:53 +01:00
#ifndef FUNCTION_PASS_WITH_PARAMS
[NewPM] Handle passes with params in -print-before/-print-after To support options like -print-before=<pass> and -print-after=<pass> the PassBuilder will register PassInstrumentation callbacks as well as a mapping between internal pass class names and the pass names used in those options (and other cmd line interfaces). But for some reason all the passes that takes options where missing in those maps, so for example "-print-after=loop-vectorize" didn't work. This patch will add the missing entries by also taking care of function and loop passes with params when setting up the class to pass name maps. One might notice that even with this patch it might be tricky to know what pass name to use in options such as -print-after. This because there only is a single mapping from class name to pass name, while the PassRegistry currently is a bit messy as it sometimes reuses the same class for different pass names (without using the "pass with params" scheme, or the pass-name<variant> syntax). It gets extra messy in some situations. For example the MemorySanitizerPass can run like this (with debug and print-after) opt -passes='kmsan' -print-after=msan-module -debug-only=msan The 'kmsan' alias for 'msan<kernel>' is just confusing as one might think that 'kmsan' is a separate pass (but the DEBUG_TYPE is still just 'msan'). And since the module pass version of the pass adds a mapping from 'MemorySanitizerPass' to 'msan-module' one need to use 'msan-module' in the print-before and print-after options. Reviewed By: ychen Differential Revision: https://reviews.llvm.org/D105006
2021-06-28 00:22:11 +02:00
#define FUNCTION_PASS_WITH_PARAMS(NAME, CLASS, CREATE_PASS, PARSER, PARAMS)
[LoopUnroll] add parsing for unroll parameters in -passes pipeline Allow to specify loop-unrolling with optional parameters explicitly spelled out in -passes pipeline specification. Introducing somewhat generic way of specifying parameters parsing via FUNCTION_PASS_PARAMETRIZED pass registration. Syntax of parametrized unroll pass name is as follows: 'unroll<' parameter-list '>' Where parameter-list is ';'-separate list of parameter names and optlevel optlevel: 'O[0-3]' parameter: { 'partial' | 'peeling' | 'runtime' | 'upperbound' } negated: 'no-' parameter Example: -passes=loop(unroll<O3;runtime;no-upperbound>) this invokes LoopUnrollPass configured with OptLevel=3, Runtime, no UpperBound, everything else by default. llvm-svn: 350808
2019-01-10 11:01:53 +01:00
#endif
[NewPM][LoopUnroll] Rename unroll* to loop-unroll* The legacy pass is called "loop-unroll", but in the new PM it's called "unroll". Also applied to unroll-and-jam and unroll-full. Fixes various check-llvm tests when NPM is turned on. Reviewed By: Whitney, dmgreen Differential Revision: https://reviews.llvm.org/D82590
2020-06-26 18:28:32 +02:00
FUNCTION_PASS_WITH_PARAMS("loop-unroll",
[NewPM] Handle passes with params in -print-before/-print-after To support options like -print-before=<pass> and -print-after=<pass> the PassBuilder will register PassInstrumentation callbacks as well as a mapping between internal pass class names and the pass names used in those options (and other cmd line interfaces). But for some reason all the passes that takes options where missing in those maps, so for example "-print-after=loop-vectorize" didn't work. This patch will add the missing entries by also taking care of function and loop passes with params when setting up the class to pass name maps. One might notice that even with this patch it might be tricky to know what pass name to use in options such as -print-after. This because there only is a single mapping from class name to pass name, while the PassRegistry currently is a bit messy as it sometimes reuses the same class for different pass names (without using the "pass with params" scheme, or the pass-name<variant> syntax). It gets extra messy in some situations. For example the MemorySanitizerPass can run like this (with debug and print-after) opt -passes='kmsan' -print-after=msan-module -debug-only=msan The 'kmsan' alias for 'msan<kernel>' is just confusing as one might think that 'kmsan' is a separate pass (but the DEBUG_TYPE is still just 'msan'). And since the module pass version of the pass adds a mapping from 'MemorySanitizerPass' to 'msan-module' one need to use 'msan-module' in the print-before and print-after options. Reviewed By: ychen Differential Revision: https://reviews.llvm.org/D105006
2021-06-28 00:22:11 +02:00
"LoopUnrollPass",
[NewPM][MSan] Add Options Handling Summary: This patch enables passing options to msan via the passes pipeline, e.e., -passes=msan<recover;kernel;track-origins=4>. Reviewers: chandlerc, fedor.sergeev, leonardchan Subscribers: hiraditya, bollu, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57640 llvm-svn: 353090
2019-02-04 22:02:49 +01:00
[](LoopUnrollOptions Opts) {
return LoopUnrollPass(Opts);
},
[NewPM] Print passes with params when using "opt -print-passes" Make sure we also print passes with params when using "opt -print-passes". Differential Revision: https://reviews.llvm.org/D104625
2021-06-21 11:22:14 +02:00
parseLoopUnrollOptions,
"O0;O1;O2;O3;full-unroll-max=N;"
"no-partial;partial;"
"no-peeling;peeling;"
"no-profile-peeling;profile-peeling;"
"no-runtime;runtime;"
"no-upperbound;upperbound")
[NewPM][MSan] Add Options Handling Summary: This patch enables passing options to msan via the passes pipeline, e.e., -passes=msan<recover;kernel;track-origins=4>. Reviewers: chandlerc, fedor.sergeev, leonardchan Subscribers: hiraditya, bollu, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57640 llvm-svn: 353090
2019-02-04 22:02:49 +01:00
FUNCTION_PASS_WITH_PARAMS("msan",
[NewPM] Handle passes with params in -print-before/-print-after To support options like -print-before=<pass> and -print-after=<pass> the PassBuilder will register PassInstrumentation callbacks as well as a mapping between internal pass class names and the pass names used in those options (and other cmd line interfaces). But for some reason all the passes that takes options where missing in those maps, so for example "-print-after=loop-vectorize" didn't work. This patch will add the missing entries by also taking care of function and loop passes with params when setting up the class to pass name maps. One might notice that even with this patch it might be tricky to know what pass name to use in options such as -print-after. This because there only is a single mapping from class name to pass name, while the PassRegistry currently is a bit messy as it sometimes reuses the same class for different pass names (without using the "pass with params" scheme, or the pass-name<variant> syntax). It gets extra messy in some situations. For example the MemorySanitizerPass can run like this (with debug and print-after) opt -passes='kmsan' -print-after=msan-module -debug-only=msan The 'kmsan' alias for 'msan<kernel>' is just confusing as one might think that 'kmsan' is a separate pass (but the DEBUG_TYPE is still just 'msan'). And since the module pass version of the pass adds a mapping from 'MemorySanitizerPass' to 'msan-module' one need to use 'msan-module' in the print-before and print-after options. Reviewed By: ychen Differential Revision: https://reviews.llvm.org/D105006
2021-06-28 00:22:11 +02:00
"MemorySanitizerPass",
[NewPM][MSan] Add Options Handling Summary: This patch enables passing options to msan via the passes pipeline, e.e., -passes=msan<recover;kernel;track-origins=4>. Reviewers: chandlerc, fedor.sergeev, leonardchan Subscribers: hiraditya, bollu, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D57640 llvm-svn: 353090
2019-02-04 22:02:49 +01:00
[](MemorySanitizerOptions Opts) {
return MemorySanitizerPass(Opts);
},
[NewPM] Print passes with params when using "opt -print-passes" Make sure we also print passes with params when using "opt -print-passes". Differential Revision: https://reviews.llvm.org/D104625
2021-06-21 11:22:14 +02:00
parseMSanPassOptions,
"recover;kernel;track-origins=N")
[NewPM] Consistently use 'simplifycfg' rather than 'simplify-cfg' There was an alias between 'simplifycfg' and 'simplify-cfg' in the PassRegistry. That was the original reason for this patch, which effectively removes the alias. This patch also replaces all occurrances of 'simplify-cfg' by 'simplifycfg'. Reason for choosing that form for the name is that it matches the DEBUG_TYPE for the pass, and the legacy PM name and also how it is spelled out in other passes such as 'loop-simplifycfg', and in other options such as 'simplifycfg-merge-cond-stores'. I for some reason the name should be changed to 'simplify-cfg' in the future, then I think such a renaming should be more widely done and not only impacting the PassRegistry. Reviewed By: aeubanks Differential Revision: https://reviews.llvm.org/D105627
2021-07-08 14:24:03 +02:00
FUNCTION_PASS_WITH_PARAMS("simplifycfg",
[NewPM] Handle passes with params in -print-before/-print-after To support options like -print-before=<pass> and -print-after=<pass> the PassBuilder will register PassInstrumentation callbacks as well as a mapping between internal pass class names and the pass names used in those options (and other cmd line interfaces). But for some reason all the passes that takes options where missing in those maps, so for example "-print-after=loop-vectorize" didn't work. This patch will add the missing entries by also taking care of function and loop passes with params when setting up the class to pass name maps. One might notice that even with this patch it might be tricky to know what pass name to use in options such as -print-after. This because there only is a single mapping from class name to pass name, while the PassRegistry currently is a bit messy as it sometimes reuses the same class for different pass names (without using the "pass with params" scheme, or the pass-name<variant> syntax). It gets extra messy in some situations. For example the MemorySanitizerPass can run like this (with debug and print-after) opt -passes='kmsan' -print-after=msan-module -debug-only=msan The 'kmsan' alias for 'msan<kernel>' is just confusing as one might think that 'kmsan' is a separate pass (but the DEBUG_TYPE is still just 'msan'). And since the module pass version of the pass adds a mapping from 'MemorySanitizerPass' to 'msan-module' one need to use 'msan-module' in the print-before and print-after options. Reviewed By: ychen Differential Revision: https://reviews.llvm.org/D105006
2021-06-28 00:22:11 +02:00
"SimplifyCFGPass",
[NewPM] Add Option handling for SimplifyCFG This patch enables passing options to SimplifyCFGPass via the passes pipeline. Reviewers: chandlerc, fedor.sergeev, leonardchan, philip.pfaffe Reviewed By: fedor.sergeev Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D60675 llvm-svn: 358379
2019-04-15 10:57:53 +02:00
[](SimplifyCFGOptions Opts) {
return SimplifyCFGPass(Opts);
},
[NewPM] Print passes with params when using "opt -print-passes" Make sure we also print passes with params when using "opt -print-passes". Differential Revision: https://reviews.llvm.org/D104625
2021-06-21 11:22:14 +02:00
parseSimplifyCFGOptions,
"no-forward-switch-cond;forward-switch-cond;"
"no-switch-to-lookup;switch-to-lookup;"
"no-keep-loops;keep-loops;"
"no-hoist-common-insts;hoist-common-insts;"
"no-sink-common-insts;sink-common-insts;"
"bonus-inst-threshold=N"
)
[NewPM] Add Option handling for LoopVectorize This patch enables passing options to LoopVectorizePass via the passes pipeline. Reviewers: chandlerc, fedor.sergeev, leonardchan, philip.pfaffe Reviewed By: fedor.sergeev Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D60681 llvm-svn: 358647
2019-04-18 10:46:11 +02:00
FUNCTION_PASS_WITH_PARAMS("loop-vectorize",
[NewPM] Handle passes with params in -print-before/-print-after To support options like -print-before=<pass> and -print-after=<pass> the PassBuilder will register PassInstrumentation callbacks as well as a mapping between internal pass class names and the pass names used in those options (and other cmd line interfaces). But for some reason all the passes that takes options where missing in those maps, so for example "-print-after=loop-vectorize" didn't work. This patch will add the missing entries by also taking care of function and loop passes with params when setting up the class to pass name maps. One might notice that even with this patch it might be tricky to know what pass name to use in options such as -print-after. This because there only is a single mapping from class name to pass name, while the PassRegistry currently is a bit messy as it sometimes reuses the same class for different pass names (without using the "pass with params" scheme, or the pass-name<variant> syntax). It gets extra messy in some situations. For example the MemorySanitizerPass can run like this (with debug and print-after) opt -passes='kmsan' -print-after=msan-module -debug-only=msan The 'kmsan' alias for 'msan<kernel>' is just confusing as one might think that 'kmsan' is a separate pass (but the DEBUG_TYPE is still just 'msan'). And since the module pass version of the pass adds a mapping from 'MemorySanitizerPass' to 'msan-module' one need to use 'msan-module' in the print-before and print-after options. Reviewed By: ychen Differential Revision: https://reviews.llvm.org/D105006
2021-06-28 00:22:11 +02:00
"LoopVectorizePass",
[NewPM] Add Option handling for LoopVectorize This patch enables passing options to LoopVectorizePass via the passes pipeline. Reviewers: chandlerc, fedor.sergeev, leonardchan, philip.pfaffe Reviewed By: fedor.sergeev Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D60681 llvm-svn: 358647
2019-04-18 10:46:11 +02:00
[](LoopVectorizeOptions Opts) {
return LoopVectorizePass(Opts);
},
[NewPM] Print passes with params when using "opt -print-passes" Make sure we also print passes with params when using "opt -print-passes". Differential Revision: https://reviews.llvm.org/D104625
2021-06-21 11:22:14 +02:00
parseLoopVectorizeOptions,
"no-interleave-forced-only;interleave-forced-only;"
"no-vectorize-forced-only;vectorize-forced-only")
[MergedLoadStoreMotion] Sink stores to BB with more than 2 predecessors If we have: bb5: br i1 %arg3, label %bb6, label %bb7 bb6: %tmp = getelementptr inbounds i32, i32* %arg1, i64 2 store i32 3, i32* %tmp, align 4 br label %bb9 bb7: %tmp8 = getelementptr inbounds i32, i32* %arg1, i64 2 store i32 3, i32* %tmp8, align 4 br label %bb9 bb9: ; preds = %bb4, %bb6, %bb7 ... We can't sink stores directly into bb9. This patch creates new BB that is successor of %bb6 and %bb7 and sinks stores into that block. SplitFooterBB is the parameter to the pass that controls that behavior. Change-Id: I7fdf50a772b84633e4b1b860e905bf7e3e29940f Differential: https://reviews.llvm.org/D66234 llvm-svn: 371089
2019-09-05 19:00:32 +02:00
FUNCTION_PASS_WITH_PARAMS("mldst-motion",
[NewPM] Handle passes with params in -print-before/-print-after To support options like -print-before=<pass> and -print-after=<pass> the PassBuilder will register PassInstrumentation callbacks as well as a mapping between internal pass class names and the pass names used in those options (and other cmd line interfaces). But for some reason all the passes that takes options where missing in those maps, so for example "-print-after=loop-vectorize" didn't work. This patch will add the missing entries by also taking care of function and loop passes with params when setting up the class to pass name maps. One might notice that even with this patch it might be tricky to know what pass name to use in options such as -print-after. This because there only is a single mapping from class name to pass name, while the PassRegistry currently is a bit messy as it sometimes reuses the same class for different pass names (without using the "pass with params" scheme, or the pass-name<variant> syntax). It gets extra messy in some situations. For example the MemorySanitizerPass can run like this (with debug and print-after) opt -passes='kmsan' -print-after=msan-module -debug-only=msan The 'kmsan' alias for 'msan<kernel>' is just confusing as one might think that 'kmsan' is a separate pass (but the DEBUG_TYPE is still just 'msan'). And since the module pass version of the pass adds a mapping from 'MemorySanitizerPass' to 'msan-module' one need to use 'msan-module' in the print-before and print-after options. Reviewed By: ychen Differential Revision: https://reviews.llvm.org/D105006
2021-06-28 00:22:11 +02:00
"MergedLoadStoreMotionPass",
[MergedLoadStoreMotion] Sink stores to BB with more than 2 predecessors If we have: bb5: br i1 %arg3, label %bb6, label %bb7 bb6: %tmp = getelementptr inbounds i32, i32* %arg1, i64 2 store i32 3, i32* %tmp, align 4 br label %bb9 bb7: %tmp8 = getelementptr inbounds i32, i32* %arg1, i64 2 store i32 3, i32* %tmp8, align 4 br label %bb9 bb9: ; preds = %bb4, %bb6, %bb7 ... We can't sink stores directly into bb9. This patch creates new BB that is successor of %bb6 and %bb7 and sinks stores into that block. SplitFooterBB is the parameter to the pass that controls that behavior. Change-Id: I7fdf50a772b84633e4b1b860e905bf7e3e29940f Differential: https://reviews.llvm.org/D66234 llvm-svn: 371089
2019-09-05 19:00:32 +02:00
[](MergedLoadStoreMotionOptions Opts) {
return MergedLoadStoreMotionPass(Opts);
},
[NewPM] Print passes with params when using "opt -print-passes" Make sure we also print passes with params when using "opt -print-passes". Differential Revision: https://reviews.llvm.org/D104625
2021-06-21 11:22:14 +02:00
parseMergedLoadStoreMotionOptions,
"no-split-footer-bb;split-footer-bb")
[GVN] add GVN parameters parsing to new pass manager Introduce parsing, add a few instances of parameter use into GVN-PRE tests. Reviewers: skatkov, asbirlea Reviewed By: skatkov Tags: #llvm Differential Revision: https://reviews.llvm.org/D72752
2020-01-16 18:31:24 +01:00
FUNCTION_PASS_WITH_PARAMS("gvn",
[NewPM] Handle passes with params in -print-before/-print-after To support options like -print-before=<pass> and -print-after=<pass> the PassBuilder will register PassInstrumentation callbacks as well as a mapping between internal pass class names and the pass names used in those options (and other cmd line interfaces). But for some reason all the passes that takes options where missing in those maps, so for example "-print-after=loop-vectorize" didn't work. This patch will add the missing entries by also taking care of function and loop passes with params when setting up the class to pass name maps. One might notice that even with this patch it might be tricky to know what pass name to use in options such as -print-after. This because there only is a single mapping from class name to pass name, while the PassRegistry currently is a bit messy as it sometimes reuses the same class for different pass names (without using the "pass with params" scheme, or the pass-name<variant> syntax). It gets extra messy in some situations. For example the MemorySanitizerPass can run like this (with debug and print-after) opt -passes='kmsan' -print-after=msan-module -debug-only=msan The 'kmsan' alias for 'msan<kernel>' is just confusing as one might think that 'kmsan' is a separate pass (but the DEBUG_TYPE is still just 'msan'). And since the module pass version of the pass adds a mapping from 'MemorySanitizerPass' to 'msan-module' one need to use 'msan-module' in the print-before and print-after options. Reviewed By: ychen Differential Revision: https://reviews.llvm.org/D105006
2021-06-28 00:22:11 +02:00
"GVN",
[GVN] add GVN parameters parsing to new pass manager Introduce parsing, add a few instances of parameter use into GVN-PRE tests. Reviewers: skatkov, asbirlea Reviewed By: skatkov Tags: #llvm Differential Revision: https://reviews.llvm.org/D72752
2020-01-16 18:31:24 +01:00
[](GVNOptions Opts) {
return GVN(Opts);
},
[NewPM] Print passes with params when using "opt -print-passes" Make sure we also print passes with params when using "opt -print-passes". Differential Revision: https://reviews.llvm.org/D104625
2021-06-21 11:22:14 +02:00
parseGVNOptions,
"no-pre;pre;"
"no-load-pre;load-pre;"
"no-split-backedge-load-pre;split-backedge-load-pre;"
"no-memdep;memdep")
[StackSafety] Add "Must Live" logic Summary: Extend StackLifetime with option to calculate liveliness where alloca is only considered alive on basic block entry if all non-dead predecessors had it alive at terminators. Depends on D82043. Reviewers: eugenis Reviewed By: eugenis Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D82124
2020-06-18 11:24:00 +02:00
FUNCTION_PASS_WITH_PARAMS("print<stack-lifetime>",
[NewPM] Handle passes with params in -print-before/-print-after To support options like -print-before=<pass> and -print-after=<pass> the PassBuilder will register PassInstrumentation callbacks as well as a mapping between internal pass class names and the pass names used in those options (and other cmd line interfaces). But for some reason all the passes that takes options where missing in those maps, so for example "-print-after=loop-vectorize" didn't work. This patch will add the missing entries by also taking care of function and loop passes with params when setting up the class to pass name maps. One might notice that even with this patch it might be tricky to know what pass name to use in options such as -print-after. This because there only is a single mapping from class name to pass name, while the PassRegistry currently is a bit messy as it sometimes reuses the same class for different pass names (without using the "pass with params" scheme, or the pass-name<variant> syntax). It gets extra messy in some situations. For example the MemorySanitizerPass can run like this (with debug and print-after) opt -passes='kmsan' -print-after=msan-module -debug-only=msan The 'kmsan' alias for 'msan<kernel>' is just confusing as one might think that 'kmsan' is a separate pass (but the DEBUG_TYPE is still just 'msan'). And since the module pass version of the pass adds a mapping from 'MemorySanitizerPass' to 'msan-module' one need to use 'msan-module' in the print-before and print-after options. Reviewed By: ychen Differential Revision: https://reviews.llvm.org/D105006
2021-06-28 00:22:11 +02:00
"StackLifetimePrinterPass",
[StackSafety] Add "Must Live" logic Summary: Extend StackLifetime with option to calculate liveliness where alloca is only considered alive on basic block entry if all non-dead predecessors had it alive at terminators. Depends on D82043. Reviewers: eugenis Reviewed By: eugenis Subscribers: hiraditya, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D82124
2020-06-18 11:24:00 +02:00
[](StackLifetime::LivenessType Type) {
return StackLifetimePrinterPass(dbgs(), Type);
},
[NewPM] Print passes with params when using "opt -print-passes" Make sure we also print passes with params when using "opt -print-passes". Differential Revision: https://reviews.llvm.org/D104625
2021-06-21 11:22:14 +02:00
parseStackLifetimeOptions,
"may;must")
[LoopUnroll] add parsing for unroll parameters in -passes pipeline Allow to specify loop-unrolling with optional parameters explicitly spelled out in -passes pipeline specification. Introducing somewhat generic way of specifying parameters parsing via FUNCTION_PASS_PARAMETRIZED pass registration. Syntax of parametrized unroll pass name is as follows: 'unroll<' parameter-list '>' Where parameter-list is ';'-separate list of parameter names and optlevel optlevel: 'O[0-3]' parameter: { 'partial' | 'peeling' | 'runtime' | 'upperbound' } negated: 'no-' parameter Example: -passes=loop(unroll<O3;runtime;no-upperbound>) this invokes LoopUnrollPass configured with OptLevel=3, Runtime, no UpperBound, everything else by default. llvm-svn: 350808
2019-01-10 11:01:53 +01:00
#undef FUNCTION_PASS_WITH_PARAMS
PM: Implement a basic loop pass manager 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
2016-02-25 08:23:08 +01:00
#ifndef LOOP_ANALYSIS
#define LOOP_ANALYSIS(NAME, CREATE_PASS)
#endif
LOOP_ANALYSIS("no-op-loop", NoOpLoopAnalysis())
[PM] name the new PM LAA class LoopAccessAnalysis (LAA) /NFC llvm-svn: 274934
2016-07-08 23:21:44 +02:00
LOOP_ANALYSIS("access-info", LoopAccessAnalysis())
Data Dependence Graph Basics Summary: This is the first patch in a series of patches that will implement data dependence graph in LLVM. Many of the ideas used in this implementation are based on the following paper: D. J. Kuck, R. H. Kuhn, D. A. Padua, B. Leasure, and M. Wolfe (1981). DEPENDENCE GRAPHS AND COMPILER OPTIMIZATIONS. This patch contains support for a basic DDGs containing only atomic nodes (one node for each instruction). The edges are two fold: def-use edges and memory-dependence edges. The implementation takes a list of basic-blocks and only considers dependencies among instructions in those basic blocks. Any dependencies coming into or going out of instructions that do not belong to those basic blocks are ignored. The algorithm for building the graph involves the following steps in order: 1. For each instruction in the range of basic blocks to consider, create an atomic node in the resulting graph. 2. For each node in the graph establish def-use edges to/from other nodes in the graph. 3. For each pair of nodes containing memory instruction(s) create memory edges between them. This part of the algorithm goes through the instructions in lexicographical order and creates edges in reverse order if the sink of the dependence occurs before the source of it. Authored By: bmahjour Reviewer: Meinersbur, fhahn, myhsu, xtian, dmgreen, kbarton, jdoerfert Reviewed By: Meinersbur, fhahn, myhsu Subscribers: ychen, arphaman, simoll, a.elovikov, mgorny, hiraditya, jfb, wuzish, llvm-commits, jsji, Whitney, etiotto Tag: #llvm Differential Revision: https://reviews.llvm.org/D65350 llvm-svn: 372238
2019-09-18 19:43:45 +02:00
LOOP_ANALYSIS("ddg", DDGAnalysis())
[NPM][IVUsers] Rename ivusers -> iv-users LPM passes were named iv-users, which seems nicer than ivusers. Reviewed By: hans Differential Revision: https://reviews.llvm.org/D83803
2020-07-15 18:34:44 +02:00
LOOP_ANALYSIS("iv-users", IVUsersAnalysis())
[New PM] Introducing PassInstrumentation framework Pass Execution Instrumentation interface enables customizable instrumentation of pass execution, as per "RFC: Pass Execution Instrumentation interface" posted 06/07/2018 on llvm-dev@ The intent is to provide a common machinery to implement all the pass-execution-debugging features like print-before/after, opt-bisect, time-passes etc. Here we get a basic implementation consisting of: * PassInstrumentationCallbacks class that handles registration of callbacks and access to them. * PassInstrumentation class that handles instrumentation-point interfaces that call into PassInstrumentationCallbacks. * Callbacks accept StringRef which is just a name of the Pass right now. There were some ideas to pass an opaque wrapper for the pointer to pass instance, however it appears that pointer does not actually identify the instance (adaptors and managers might have the same address with the pass they govern). Hence it was decided to go simple for now and then later decide on what the proper mental model of identifying a "pass in a phase of pipeline" is. * Callbacks accept llvm::Any serving as a wrapper for const IRUnit*, to remove direct dependencies on different IRUnits (e.g. Analyses). * PassInstrumentationAnalysis analysis is explicitly requested from PassManager through usual AnalysisManager::getResult. All pass managers were updated to run that to get PassInstrumentation object for instrumentation calls. * Using tuples/index_sequence getAnalysisResult helper to extract generic AnalysisManager's extra args out of a generic PassManager's extra args. This is the only way I was able to explicitly run getResult for PassInstrumentationAnalysis out of a generic code like PassManager::run or RepeatedPass::run. TODO: Upon lengthy discussions we agreed to accept this as an initial implementation and then get rid of getAnalysisResult by improving RepeatedPass implementation. * PassBuilder takes PassInstrumentationCallbacks object to pass it further into PassInstrumentationAnalysis. Callbacks registration should be performed directly through PassInstrumentationCallbacks. * new-pm tests updated to account for PassInstrumentationAnalysis being run * Added PassInstrumentation tests to PassBuilderCallbacks unit tests. Other unit tests updated with registration of the now-required PassInstrumentationAnalysis. Made getName helper to return std::string (instead of StringRef initially) to fix asan builtbot failures on CGSCC tests. Reviewers: chandlerc, philip.pfaffe Differential Revision: https://reviews.llvm.org/D47858 llvm-svn: 342664
2018-09-20 19:08:45 +02:00
LOOP_ANALYSIS("pass-instrumentation", PassInstrumentationAnalysis(PIC))
PM: Implement a basic loop pass manager 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
2016-02-25 08:23:08 +01:00
#undef LOOP_ANALYSIS
#ifndef LOOP_PASS
#define LOOP_PASS(NAME, CREATE_PASS)
#endif
Add CanonicalizeFreezeInLoops pass Summary: If an induction variable is frozen and used, SCEV yields imprecise result because it doesn't say anything about frozen variables. Due to this reason, performance degradation happened after https://reviews.llvm.org/D76483 is merged, causing SCEV yield imprecise result and preventing LSR to optimize a loop. The suggested solution here is to add a pass which canonicalizes frozen variables inside a loop. To be specific, it pushes freezes out of the loop by freezing the initial value and step values instead & dropping nsw/nuw flags from instructions used by freeze. This solution was also mentioned at https://reviews.llvm.org/D70623 . Reviewers: spatel, efriedma, lebedev.ri, fhahn, jdoerfert Reviewed By: fhahn Subscribers: nikic, mgorny, hiraditya, javed.absar, llvm-commits, sanwou01, nlopes Tags: #llvm Differential Revision: https://reviews.llvm.org/D77523
2020-05-07 22:28:42 +02:00
LOOP_PASS("canon-freeze", CanonicalizeFreezeInLoopsPass())
[DDG] Data Dependence Graph - DOT printer - recommit This is being recommitted to try and address the MSVC complaint. This patch implements a DDG printer pass that generates a graph in the DOT description language, providing a more visually appealing representation of the DDG. Similar to the CFG DOT printer, this functionality is provided under an option called -dot-ddg and can be generated in a less verbose mode under -dot-ddg-only option. Reviewed By: Meinersbur Differential Revision: https://reviews.llvm.org/D90159
2020-12-16 18:34:38 +01:00
LOOP_PASS("dot-ddg", DDGDotPrinterPass())
PM: Implement a basic loop pass manager 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
2016-02-25 08:23:08 +01:00
LOOP_PASS("invalidate<all>", InvalidateAllAnalysesPass())
Add missing files for r275222 New pass manager for LICM. Summary: Port LICM to the new pass manager. Reviewers: davidxl, silvas Subscribers: krasin, vitalybuka, silvas, davide, sanjoy, llvm-commits, mehdi_amini Differential Revision: http://reviews.llvm.org/D21772 llvm-svn: 275224
2016-07-13 00:42:24 +02:00
LOOP_PASS("licm", LICMPass())
[LICM] Create LoopNest Invariant Code Motion (LNICM) pass This patch adds a new pass called LNICM which is a LoopNest version of LICM and a test case to show how LNICM works. Basically, LNICM only hoists invariants out of loop nest (not a loop) to keep/make perfect loop nest. This enables later optimizations that require perfect loop nest. Reviewed By: Whitney Differential Revision: https://reviews.llvm.org/D104180
2021-07-19 17:31:18 +02:00
LOOP_PASS("lnicm", LNICMPass())
[LoopNest][LoopFlatten] Change LoopFlattenPass to LoopNest pass This patch changes LoopFlattenPass from FunctionPass to LoopNestPass. Utilize LoopNest and let function 'Flatten' generate information from it. Reviewed By: Whitney Differential Revision: https://reviews.llvm.org/D102904
2021-05-28 08:58:10 +02:00
LOOP_PASS("loop-flatten", LoopFlattenPass())
[PM] Port LoopIdiomRecognize Pass to new PM Summary: Port LoopIdiomRecognize Pass to new PM Reviewers: davidxl Subscribers: davide, sanjoy, mzolotukhin, llvm-commits Differential Revision: http://reviews.llvm.org/D22250 llvm-svn: 275202
2016-07-12 20:45:51 +02:00
LOOP_PASS("loop-idiom", LoopIdiomRecognizePass())
Restore the LoopInstSimplify pass, reverting r327329 that removed it. The plan had always been to move towards using this rather than so much in-pass simplification within the loop pipeline, but we never got around to it.... until only a couple months after it was removed due to disuse. =/ This commit is just a pure revert of the removal. I will add tests and do some basic cleanup in follow-up commits. Then I'll wire it into the loop pass pipeline. Differential Revision: https://reviews.llvm.org/D47353 llvm-svn: 333250
2018-05-25 03:32:36 +02:00
LOOP_PASS("loop-instsimplify", LoopInstSimplifyPass())
[LoopInterchange][NewPM] Port -loop-interchange to NPM Reviewed By: fhahn Differential Revision: https://reviews.llvm.org/D89058
2020-09-18 01:19:04 +02:00
LOOP_PASS("loop-interchange", LoopInterchangePass())
[NewPM][LoopRotate] Rename rotate -> loop-rotate To match legacy pass name. Reviewed By: ychen Differential Revision: https://reviews.llvm.org/D85338
2020-08-05 21:22:07 +02:00
LOOP_PASS("loop-rotate", LoopRotatePass())
PM: Implement a basic loop pass manager 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
2016-02-25 08:23:08 +01:00
LOOP_PASS("no-op-loop", NoOpLoopPass())
LOOP_PASS("print", PrintLoopPass(dbgs()))
[PM] Port Dead Loop Deletion Pass to the new PM Summary: Port Dead Loop Deletion Pass to the new pass manager. Reviewers: silvas, davide Subscribers: llvm-commits, sanjoy, mcrosier Differential Revision: https://reviews.llvm.org/D21483 llvm-svn: 275453
2016-07-14 20:28:29 +02:00
LOOP_PASS("loop-deletion", LoopDeletionPass())
[LoopSimplifyCFG][NewPM] Rename simplify-cfg -> loop-simplifycfg This matches the legacy PM name and makes all tests in Transforms/LoopSimplifyCFG pass under NPM. Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D87948
2020-09-18 23:43:36 +02:00
LOOP_PASS("loop-simplifycfg", LoopSimplifyCFGPass())
[NewPM][LSR] Rename strength-reduce -> loop-reduce The legacy pass was called "loop-reduce". This lowers the number of check-llvm failures under NPM by 83. Reviewed By: ychen Differential Revision: https://reviews.llvm.org/D82925
2020-07-02 20:15:29 +02:00
LOOP_PASS("loop-reduce", LoopStrengthReducePass())
[PM] Port IndVarSimplify to the new pass manager Summary: There are some rough corners, since the new pass manager doesn't have (as far as I can tell) LoopSimplify and LCSSA, so I've updated the tests to run them separately in the old pass manager in the lit tests. We also don't have an equivalent for AU.setPreservesCFG() in the new pass manager, so I've left a FIXME. Reviewers: bogner, chandlerc, davide Subscribers: sanjoy, mcrosier, llvm-commits Differential Revision: http://reviews.llvm.org/D20783 llvm-svn: 271846
2016-06-05 20:01:19 +02:00
LOOP_PASS("indvars", IndVarSimplifyPass())
[LoopUnrollAndJam] Change LoopUnrollAndJamPass to LoopNest pass This patch changes LoopUnrollAndJamPass from FunctionPass to LoopNest pass. The next patch will utilize LoopNest to effectively handle loop nests. Also, a crash problem on legacy pass manager is fixed. Reviewed By: Whitney Differential Revision: https://reviews.llvm.org/D99149
2021-06-08 13:29:48 +02:00
LOOP_PASS("loop-unroll-and-jam", LoopUnrollAndJamPass())
[NewPM][LoopUnroll] Rename unroll* to loop-unroll* The legacy pass is called "loop-unroll", but in the new PM it's called "unroll". Also applied to unroll-and-jam and unroll-full. Fixes various check-llvm tests when NPM is turned on. Reviewed By: Whitney, dmgreen Differential Revision: https://reviews.llvm.org/D82590
2020-06-26 18:28:32 +02:00
LOOP_PASS("loop-unroll-full", LoopFullUnrollPass())
[PM] Port LoopAccessInfo analysis to new PM It is implemented as a LoopAnalysis pass as discussed and agreed upon. llvm-svn: 274452
2016-07-02 23:18:40 +02:00
LOOP_PASS("print-access-info", LoopAccessInfoPrinterPass(dbgs()))
Data Dependence Graph Basics Summary: This is the first patch in a series of patches that will implement data dependence graph in LLVM. Many of the ideas used in this implementation are based on the following paper: D. J. Kuck, R. H. Kuhn, D. A. Padua, B. Leasure, and M. Wolfe (1981). DEPENDENCE GRAPHS AND COMPILER OPTIMIZATIONS. This patch contains support for a basic DDGs containing only atomic nodes (one node for each instruction). The edges are two fold: def-use edges and memory-dependence edges. The implementation takes a list of basic-blocks and only considers dependencies among instructions in those basic blocks. Any dependencies coming into or going out of instructions that do not belong to those basic blocks are ignored. The algorithm for building the graph involves the following steps in order: 1. For each instruction in the range of basic blocks to consider, create an atomic node in the resulting graph. 2. For each node in the graph establish def-use edges to/from other nodes in the graph. 3. For each pair of nodes containing memory instruction(s) create memory edges between them. This part of the algorithm goes through the instructions in lexicographical order and creates edges in reverse order if the sink of the dependence occurs before the source of it. Authored By: bmahjour Reviewer: Meinersbur, fhahn, myhsu, xtian, dmgreen, kbarton, jdoerfert Reviewed By: Meinersbur, fhahn, myhsu Subscribers: ychen, arphaman, simoll, a.elovikov, mgorny, hiraditya, jfb, wuzish, llvm-commits, jsji, Whitney, etiotto Tag: #llvm Differential Revision: https://reviews.llvm.org/D65350 llvm-svn: 372238
2019-09-18 19:43:45 +02:00
LOOP_PASS("print<ddg>", DDGAnalysisPrinterPass(dbgs()))
[NPM][IVUsers] Rename ivusers -> iv-users LPM passes were named iv-users, which seems nicer than ivusers. Reviewed By: hans Differential Revision: https://reviews.llvm.org/D83803
2020-07-15 18:34:44 +02:00
LOOP_PASS("print<iv-users>", IVUsersPrinterPass(dbgs()))
[LoopNest]: Analysis to discover properties of a loop nest. Summary: This patch adds an analysis pass to collect loop nests and summarize properties of the nest (e.g the nest depth, whether the nest is perfect, what's the innermost loop, etc...). The motivation for this patch was discussed at the latest meeting of the LLVM loop group (https://ibm.box.com/v/llvm-loop-nest-analysis) where we discussed the unimodular loop transformation framework ( “A Loop Transformation Theory and an Algorithm to Maximize Parallelism”, Michael E. Wolf and Monica S. Lam, IEEE TPDS, October 1991). The unimodular framework provides a convenient way to unify legality checking and code generation for several loop nest transformations (e.g. loop reversal, loop interchange, loop skewing) and their compositions. Given that the unimodular framework is applicable to perfect loop nests this is one property of interest we expose in this analysis. Several other utility functions are also provided. In the future other properties of interest can be added in a centralized place. Authored By: etiotto Reviewer: Meinersbur, bmahjour, kbarton, Whitney, dmgreen, fhahn, reames, hfinkel, jdoerfert, ppc-slack Reviewed By: Meinersbur Subscribers: bryanpkc, ppc-slack, mgorny, hiraditya, llvm-commits Tag: LLVM Differential Revision: https://reviews.llvm.org/D68789
2020-03-03 18:38:19 +01:00
LOOP_PASS("print<loopnest>", LoopNestPrinterPass(dbgs()))
Title: Loop Cache Analysis Summary: Implement a new analysis to estimate the number of cache lines required by a loop nest. The analysis is largely based on the following paper: Compiler Optimizations for Improving Data Locality By: Steve Carr, Katherine S. McKinley, Chau-Wen Tseng http://www.cs.utexas.edu/users/mckinley/papers/asplos-1994.pdf The analysis considers temporal reuse (accesses to the same memory location) and spatial reuse (accesses to memory locations within a cache line). For simplicity the analysis considers memory accesses in the innermost loop in a loop nest, and thus determines the number of cache lines used when the loop L in loop nest LN is placed in the innermost position. The result of the analysis can be used to drive several transformations. As an example, loop interchange could use it determine which loops in a perfect loop nest should be interchanged to maximize cache reuse. Similarly, loop distribution could be enhanced to take into consideration cache reuse between arrays when distributing a loop to eliminate vectorization inhibiting dependencies. The general approach taken to estimate the number of cache lines used by the memory references in the inner loop of a loop nest is: Partition memory references that exhibit temporal or spatial reuse into reference groups. For each loop L in the a loop nest LN: a. Compute the cost of the reference group b. Compute the 'cache cost' of the loop nest by summing up the reference groups costs For further details of the algorithm please refer to the paper. Authored By: etiotto Reviewers: hfinkel, Meinersbur, jdoerfert, kbarton, bmahjour, anemet, fhahn Reviewed By: Meinersbur Subscribers: reames, nemanjai, MaskRay, wuzish, Hahnfeld, xusx595, venkataramanan.kumar.llvm, greened, dmgreen, steleman, fhahn, xblvaOO, Whitney, mgorny, hiraditya, mgrang, jsji, llvm-commits Tag: LLVM Differential Revision: https://reviews.llvm.org/D63459 llvm-svn: 368439
2019-08-09 15:56:29 +02:00
LOOP_PASS("print<loop-cache-cost>", LoopCachePrinterPass(dbgs()))
[Guards] Introduce loop-predication pass 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
2017-01-25 17:00:44 +01:00
LOOP_PASS("loop-predication", LoopPredicationPass())
[GuardWidening] Wire up a NPM version of the LoopGuardWidening pass llvm-svn: 358704
2019-04-18 21:17:14 +02:00
LOOP_PASS("guard-widening", GuardWideningPass())
[SimpleLoopBoundSplit] Split Bound of Loop which has conditional branch with IV This pass transforms loops that contain a conditional branch with induction variable. For example, it transforms left code to right code: newbound = min(n, c) while (iv < n) { while(iv < newbound) { A A if (iv < c) B B C C } } if (iv != n) { while (iv < n) { A C } } Differential Revision: https://reviews.llvm.org/D102234
2021-05-06 16:53:00 +02:00
LOOP_PASS("loop-bound-split", LoopBoundSplitPass())
[LoopReroll][NewPM] Port -loop-reroll to NPM Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D87957
2020-09-19 02:25:40 +02:00
LOOP_PASS("loop-reroll", LoopRerollPass())
[NPM] Port -loop-versioning-licm to NPM Reviewed By: aeubanks Differential Revision: https://reviews.llvm.org/D89371
2020-10-24 15:50:33 +02:00
LOOP_PASS("loop-versioning-licm", LoopVersioningLICMPass())
PM: Implement a basic loop pass manager 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
2016-02-25 08:23:08 +01:00
#undef LOOP_PASS
[NewPM] Add Option handling for SimpleLoopUnswitch This patch enables passing options to SimpleLoopUnswitch via the passes pipeline. Reviewers: chandlerc, fedor.sergeev, leonardchan, philip.pfaffe Reviewed By: fedor.sergeev Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D60676 llvm-svn: 358880
2019-04-22 12:35:07 +02:00
#ifndef LOOP_PASS_WITH_PARAMS
[NewPM] Handle passes with params in -print-before/-print-after To support options like -print-before=<pass> and -print-after=<pass> the PassBuilder will register PassInstrumentation callbacks as well as a mapping between internal pass class names and the pass names used in those options (and other cmd line interfaces). But for some reason all the passes that takes options where missing in those maps, so for example "-print-after=loop-vectorize" didn't work. This patch will add the missing entries by also taking care of function and loop passes with params when setting up the class to pass name maps. One might notice that even with this patch it might be tricky to know what pass name to use in options such as -print-after. This because there only is a single mapping from class name to pass name, while the PassRegistry currently is a bit messy as it sometimes reuses the same class for different pass names (without using the "pass with params" scheme, or the pass-name<variant> syntax). It gets extra messy in some situations. For example the MemorySanitizerPass can run like this (with debug and print-after) opt -passes='kmsan' -print-after=msan-module -debug-only=msan The 'kmsan' alias for 'msan<kernel>' is just confusing as one might think that 'kmsan' is a separate pass (but the DEBUG_TYPE is still just 'msan'). And since the module pass version of the pass adds a mapping from 'MemorySanitizerPass' to 'msan-module' one need to use 'msan-module' in the print-before and print-after options. Reviewed By: ychen Differential Revision: https://reviews.llvm.org/D105006
2021-06-28 00:22:11 +02:00
#define LOOP_PASS_WITH_PARAMS(NAME, CLASS, CREATE_PASS, PARSER, PARAMS)
[NewPM] Add Option handling for SimpleLoopUnswitch This patch enables passing options to SimpleLoopUnswitch via the passes pipeline. Reviewers: chandlerc, fedor.sergeev, leonardchan, philip.pfaffe Reviewed By: fedor.sergeev Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D60676 llvm-svn: 358880
2019-04-22 12:35:07 +02:00
#endif
[NewPM] Rename 'unswitch' to 'simple-loop-unswitch' in PassRegistry It is confusing to have two ways of specifying the same pass ('simple-loop-unswitch' and 'unswitch'). This patch replaces 'unswitch' by 'simple-loop-unswitch' to get a unique identifier. Using 'simple-loop-unswitch' instead of 'unswitch' also has the advantage of matching how the pass is named in DEBUG_TYPE etc. So this makes it a bit more consistent how we refer to the pass in options such as -passes, -print-after and -debug-only. Reviewed By: aeubanks Differential Revision: https://reviews.llvm.org/D105628
2021-07-08 14:12:19 +02:00
LOOP_PASS_WITH_PARAMS("simple-loop-unswitch",
[NewPM] Handle passes with params in -print-before/-print-after To support options like -print-before=<pass> and -print-after=<pass> the PassBuilder will register PassInstrumentation callbacks as well as a mapping between internal pass class names and the pass names used in those options (and other cmd line interfaces). But for some reason all the passes that takes options where missing in those maps, so for example "-print-after=loop-vectorize" didn't work. This patch will add the missing entries by also taking care of function and loop passes with params when setting up the class to pass name maps. One might notice that even with this patch it might be tricky to know what pass name to use in options such as -print-after. This because there only is a single mapping from class name to pass name, while the PassRegistry currently is a bit messy as it sometimes reuses the same class for different pass names (without using the "pass with params" scheme, or the pass-name<variant> syntax). It gets extra messy in some situations. For example the MemorySanitizerPass can run like this (with debug and print-after) opt -passes='kmsan' -print-after=msan-module -debug-only=msan The 'kmsan' alias for 'msan<kernel>' is just confusing as one might think that 'kmsan' is a separate pass (but the DEBUG_TYPE is still just 'msan'). And since the module pass version of the pass adds a mapping from 'MemorySanitizerPass' to 'msan-module' one need to use 'msan-module' in the print-before and print-after options. Reviewed By: ychen Differential Revision: https://reviews.llvm.org/D105006
2021-06-28 00:22:11 +02:00
"SimpleLoopUnswitchPass",
[NewPM][SimpleLoopUnswitch] Add option to not trivially unswitch To help with debugging non-trivial unswitching issues. Don't care about the legacy pass, nobody is using it. If a pass's string params are empty (e.g. "simple-loop-unswitch"), don't default to the empty constructor for the pass params. We should still let the parser take care of it in case the parser has its own defaults. Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D105933
2021-07-13 21:50:34 +02:00
[](std::pair<bool, bool> Params) {
return SimpleLoopUnswitchPass(Params.first, Params.second);
[NewPM] Print passes with params when using "opt -print-passes" Make sure we also print passes with params when using "opt -print-passes". Differential Revision: https://reviews.llvm.org/D104625
2021-06-21 11:22:14 +02:00
},
parseLoopUnswitchOptions,
[NewPM][SimpleLoopUnswitch] Add option to not trivially unswitch To help with debugging non-trivial unswitching issues. Don't care about the legacy pass, nobody is using it. If a pass's string params are empty (e.g. "simple-loop-unswitch"), don't default to the empty constructor for the pass params. We should still let the parser take care of it in case the parser has its own defaults. Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D105933
2021-07-13 21:50:34 +02:00
"nontrivial;no-nontrivial;trivial;no-trivial")
[NewPM] Add Option handling for SimpleLoopUnswitch This patch enables passing options to SimpleLoopUnswitch via the passes pipeline. Reviewers: chandlerc, fedor.sergeev, leonardchan, philip.pfaffe Reviewed By: fedor.sergeev Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D60676 llvm-svn: 358880
2019-04-22 12:35:07 +02:00
#undef LOOP_PASS_WITH_PARAMS
Reference in New Issue Copy Permalink