maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/Other/new-pm-lto-defaults.ll

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

159 lines
7.9 KiB
LLVM
Raw Normal View History

[PM] Flesh out the new pass manager LTO pipeline. Differential Revision: https://reviews.llvm.org/D28996 llvm-svn: 292863
2017-01-24 08:57:39 +08:00
; Basic test for the new LTO pipeline.
; For now the only difference is between -O1 and everything else, so
; -O2, -O3, -Os, -Oz are the same.
[NewPM] Change tests to run them without PreserveCFGChecker. NFC Change several pass sequence sensitive tests to be indifferent to the PreserveCFGChecker by explicitly settting the option -verify-cfg-preserved=0. It is a preparation step that allows a redesign of PreserveCFGChecker. Reviewed By: skatkov Differential Revision: https://reviews.llvm.org/D99878
2021-04-06 12:31:07 +08:00
; RUN: opt -disable-verify -verify-cfg-preserved=0 -debug-pass-manager \
[PM] Flesh out the new pass manager LTO pipeline. Differential Revision: https://reviews.llvm.org/D28996 llvm-svn: 292863
2017-01-24 08:57:39 +08:00
; RUN: -passes='lto<O1>' -S %s 2>&1 \
[ICP] Migrate to OptimizationRemarkEmitter This is a module pass so for the old PM, we can't use ORE, the function analysis pass. Instead ORE is created on the fly. A few notes: - isPromotionLegal is folded in the caller since we want to emit the Function in the remark but we can only do that if the symbol table look-up succeeded. - There was good test coverage for remarks in this pass. - promoteIndirectCall uses ORE conditionally since it's also used from SampleProfile which does not use ORE yet. Fixes PR33792. Differential Revision: https://reviews.llvm.org/D35929 llvm-svn: 309294
2017-07-28 00:54:15 +08:00
; RUN: | FileCheck %s --check-prefix=CHECK-O --check-prefix=CHECK-O1
[NewPM] Change tests to run them without PreserveCFGChecker. NFC Change several pass sequence sensitive tests to be indifferent to the PreserveCFGChecker by explicitly settting the option -verify-cfg-preserved=0. It is a preparation step that allows a redesign of PreserveCFGChecker. Reviewed By: skatkov Differential Revision: https://reviews.llvm.org/D99878
2021-04-06 12:31:07 +08:00
; RUN: opt -disable-verify -verify-cfg-preserved=0 -debug-pass-manager \
[PM] Flesh out the new pass manager LTO pipeline. Differential Revision: https://reviews.llvm.org/D28996 llvm-svn: 292863
2017-01-24 08:57:39 +08:00
; RUN: -passes='lto<O2>' -S %s 2>&1 \
[NPM][LTO] Update buildLTODefaultPipeline to be more in-line with the old pass manager The NPM LTO pipeline has a lot of fixme's and missing passes, causing a lot of regressions after the switch in c70737b. Notably unrolling and vectorization were both disabled, but many other passes are missing compared to the old pass manager. This attempt to enable the most obvious missing passes like the unroller, vectorization and other loop passes, fixing the existing FIXME comments. Differential Revision: https://reviews.llvm.org/D96780
2021-02-18 00:56:28 +08:00
; RUN: | FileCheck %s --check-prefix=CHECK-O --check-prefix=CHECK-O23SZ \
; RUN: --check-prefix=CHECK-O2
[NewPM] Change tests to run them without PreserveCFGChecker. NFC Change several pass sequence sensitive tests to be indifferent to the PreserveCFGChecker by explicitly settting the option -verify-cfg-preserved=0. It is a preparation step that allows a redesign of PreserveCFGChecker. Reviewed By: skatkov Differential Revision: https://reviews.llvm.org/D99878
2021-04-06 12:31:07 +08:00
; RUN: opt -disable-verify -verify-cfg-preserved=0 -debug-pass-manager \
[PM] Flesh out the new pass manager LTO pipeline. Differential Revision: https://reviews.llvm.org/D28996 llvm-svn: 292863
2017-01-24 08:57:39 +08:00
; RUN: -passes='lto<O3>' -S %s 2>&1 \
[NPM][LTO] Update buildLTODefaultPipeline to be more in-line with the old pass manager The NPM LTO pipeline has a lot of fixme's and missing passes, causing a lot of regressions after the switch in c70737b. Notably unrolling and vectorization were both disabled, but many other passes are missing compared to the old pass manager. This attempt to enable the most obvious missing passes like the unroller, vectorization and other loop passes, fixing the existing FIXME comments. Differential Revision: https://reviews.llvm.org/D96780
2021-02-18 00:56:28 +08:00
; RUN: | FileCheck %s --check-prefix=CHECK-O --check-prefix=CHECK-O23SZ \
Another try to commit 323321 (aggressive instruction combine). llvm-svn: 323416
2018-01-25 20:06:32 +08:00
; RUN: --check-prefix=CHECK-O3
[NewPM] Change tests to run them without PreserveCFGChecker. NFC Change several pass sequence sensitive tests to be indifferent to the PreserveCFGChecker by explicitly settting the option -verify-cfg-preserved=0. It is a preparation step that allows a redesign of PreserveCFGChecker. Reviewed By: skatkov Differential Revision: https://reviews.llvm.org/D99878
2021-04-06 12:31:07 +08:00
; RUN: opt -disable-verify -verify-cfg-preserved=0 -debug-pass-manager \
[PM] Flesh out the new pass manager LTO pipeline. Differential Revision: https://reviews.llvm.org/D28996 llvm-svn: 292863
2017-01-24 08:57:39 +08:00
; RUN: -passes='lto<Os>' -S %s 2>&1 \
[NPM][LTO] Update buildLTODefaultPipeline to be more in-line with the old pass manager The NPM LTO pipeline has a lot of fixme's and missing passes, causing a lot of regressions after the switch in c70737b. Notably unrolling and vectorization were both disabled, but many other passes are missing compared to the old pass manager. This attempt to enable the most obvious missing passes like the unroller, vectorization and other loop passes, fixing the existing FIXME comments. Differential Revision: https://reviews.llvm.org/D96780
2021-02-18 00:56:28 +08:00
; RUN: | FileCheck %s --check-prefix=CHECK-O --check-prefix=CHECK-O23SZ \
; RUN: --check-prefix=CHECK-OS
[NewPM] Change tests to run them without PreserveCFGChecker. NFC Change several pass sequence sensitive tests to be indifferent to the PreserveCFGChecker by explicitly settting the option -verify-cfg-preserved=0. It is a preparation step that allows a redesign of PreserveCFGChecker. Reviewed By: skatkov Differential Revision: https://reviews.llvm.org/D99878
2021-04-06 12:31:07 +08:00
; RUN: opt -disable-verify -verify-cfg-preserved=0 -debug-pass-manager \
[PM] Flesh out the new pass manager LTO pipeline. Differential Revision: https://reviews.llvm.org/D28996 llvm-svn: 292863
2017-01-24 08:57:39 +08:00
; RUN: -passes='lto<Oz>' -S %s 2>&1 \
[NPM][LTO] Update buildLTODefaultPipeline to be more in-line with the old pass manager The NPM LTO pipeline has a lot of fixme's and missing passes, causing a lot of regressions after the switch in c70737b. Notably unrolling and vectorization were both disabled, but many other passes are missing compared to the old pass manager. This attempt to enable the most obvious missing passes like the unroller, vectorization and other loop passes, fixing the existing FIXME comments. Differential Revision: https://reviews.llvm.org/D96780
2021-02-18 00:56:28 +08:00
; RUN: | FileCheck %s --check-prefix=CHECK-O --check-prefix=CHECK-O23SZ
[NewPM] Change tests to run them without PreserveCFGChecker. NFC Change several pass sequence sensitive tests to be indifferent to the PreserveCFGChecker by explicitly settting the option -verify-cfg-preserved=0. It is a preparation step that allows a redesign of PreserveCFGChecker. Reviewed By: skatkov Differential Revision: https://reviews.llvm.org/D99878
2021-04-06 12:31:07 +08:00
; RUN: opt -disable-verify -verify-cfg-preserved=0 -debug-pass-manager \
[PM] Enable registration of out-of-tree passes with PassBuilder Summary: This patch adds a callback registration API to the PassBuilder, enabling registering out-of-tree passes with it. Through the Callback API, callers may register callbacks with the various stages at which passes are added into pass managers, including parsing of a pass pipeline as well as at extension points within the default -O pipelines. Registering utilities like `require<>` and `invalidate<>` needs to be handled manually by the caller, but a helper is provided. Additionally, adding passes at pipeline extension points is exposed through the opt tool. This patch adds a `-passes-ep-X` commandline option for every extension point X, which opt parses into pipelines inserted into that extension point. Reviewers: chandlerc Reviewed By: chandlerc Subscribers: lksbhm, grosser, davide, mehdi_amini, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D33464 llvm-svn: 307532
2017-07-10 18:57:55 +08:00
; RUN: -passes='lto<O3>' -S %s -passes-ep-peephole='no-op-function' 2>&1 \
[NPM][LTO] Update buildLTODefaultPipeline to be more in-line with the old pass manager The NPM LTO pipeline has a lot of fixme's and missing passes, causing a lot of regressions after the switch in c70737b. Notably unrolling and vectorization were both disabled, but many other passes are missing compared to the old pass manager. This attempt to enable the most obvious missing passes like the unroller, vectorization and other loop passes, fixing the existing FIXME comments. Differential Revision: https://reviews.llvm.org/D96780
2021-02-18 00:56:28 +08:00
; RUN: | FileCheck %s --check-prefix=CHECK-O --check-prefix=CHECK-O23SZ \
Another try to commit 323321 (aggressive instruction combine). llvm-svn: 323416
2018-01-25 20:06:32 +08:00
; RUN: --check-prefix=CHECK-O3 --check-prefix=CHECK-EP-Peephole
[PM] Flesh out the new pass manager LTO pipeline. Differential Revision: https://reviews.llvm.org/D28996 llvm-svn: 292863
2017-01-24 08:57:39 +08:00
[NewPM] Hide pass manager debug logging behind -debug-pass-manager-verbose Printing pass manager invocations is fairly verbose and not super useful. This allows us to remove DebugLogging from pass managers and PassBuilder since all logging (aside from analysis managers) goes through instrumentation now. This has the downside of never being able to print the top level pass manager via instrumentation, but that seems like a minor downside. Reviewed By: ychen Differential Revision: https://reviews.llvm.org/D101797
2021-05-04 07:09:56 +08:00
; CHECK-O: Running pass: Annotation2Metadata
[PM] Flesh out the new pass manager LTO pipeline. Differential Revision: https://reviews.llvm.org/D28996 llvm-svn: 292863
2017-01-24 08:57:39 +08:00
; CHECK-O-NEXT: Running pass: GlobalDCEPass
; CHECK-O-NEXT: Running pass: ForceFunctionAttrsPass
; CHECK-O-NEXT: Running pass: InferFunctionAttrsPass
Change TargetLibraryInfo analysis passes to always require Function Summary: This is the first change to enable the TLI to be built per-function so that -fno-builtin* handling can be migrated to use function attributes. See discussion on D61634 for background. This is an enabler for fixing handling of these options for LTO, for example. This change should not affect behavior, as the provided function is not yet used to build a specifically per-function TLI, but rather enables that migration. Most of the changes were very mechanical, e.g. passing a Function to the legacy analysis pass's getTLI interface, or in Module level cases, adding a callback. This is similar to the way the per-function TTI analysis works. There was one place where we were looking for builtins but not in the context of a specific function. See FindCXAAtExit in lib/Transforms/IPO/GlobalOpt.cpp. I'm somewhat concerned my workaround could provide the wrong behavior in some corner cases. Suggestions welcome. Reviewers: chandlerc, hfinkel Subscribers: arsenm, dschuff, jvesely, nhaehnle, mehdi_amini, javed.absar, sbc100, jgravelle-google, eraman, aheejin, steven_wu, george.burgess.iv, dexonsmith, jfb, asbirlea, gchatelet, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66428 llvm-svn: 371284
2019-09-07 11:09:36 +08:00
; CHECK-O-NEXT: Running analysis: InnerAnalysisManagerProxy<{{.*}}Module
[PM] Flesh out the new pass manager LTO pipeline. Differential Revision: https://reviews.llvm.org/D28996 llvm-svn: 292863
2017-01-24 08:57:39 +08:00
; CHECK-O-NEXT: Running analysis: TargetLibraryAnalysis
[NPM][LTO] Update buildLTODefaultPipeline to be more in-line with the old pass manager The NPM LTO pipeline has a lot of fixme's and missing passes, causing a lot of regressions after the switch in c70737b. Notably unrolling and vectorization were both disabled, but many other passes are missing compared to the old pass manager. This attempt to enable the most obvious missing passes like the unroller, vectorization and other loop passes, fixing the existing FIXME comments. Differential Revision: https://reviews.llvm.org/D96780
2021-02-18 00:56:28 +08:00
; CHECK-O23SZ-NEXT: Running pass: CallSiteSplittingPass on foo
; CHECK-O23SZ-NEXT: Running analysis: TargetLibraryAnalysis on foo
; CHECK-O23SZ-NEXT: Running analysis: TargetIRAnalysis on foo
; CHECK-O23SZ-NEXT: Running analysis: DominatorTreeAnalysis on foo
; CHECK-O23SZ-NEXT: PGOIndirectCallPromotion
; CHECK-O23SZ-NEXT: Running analysis: ProfileSummaryAnalysis
; CHECK-O23SZ-NEXT: Running analysis: OptimizationRemarkEmitterAnalysis
; CHECK-O23SZ-NEXT: Running pass: IPSCCPPass
; CHECK-O23SZ-NEXT: Running analysis: AssumptionAnalysis on foo
; CHECK-O23SZ-NEXT: Running pass: CalledValuePropagationPass
Relax the matching in these tests Looks like the template arguments are displayed differently depending on the host compiler(?). E.g.: InnerAnalysisManagerProxy<CGSCCAnalysisManager InnerAnalysisManagerProxy<llvm::AnalysisManager<llvm::LazyCallGraph::SCC, ... Fix fallout after r309294 llvm-svn: 309297
2017-07-28 01:45:02 +08:00
; CHECK-O-NEXT: Running analysis: InnerAnalysisManagerProxy<{{.*}}SCC
[PM] Flesh out the new pass manager LTO pipeline. Differential Revision: https://reviews.llvm.org/D28996 llvm-svn: 292863
2017-01-24 08:57:39 +08:00
; CHECK-O-NEXT: Running analysis: LazyCallGraphAnalysis
Change TargetLibraryInfo analysis passes to always require Function Summary: This is the first change to enable the TLI to be built per-function so that -fno-builtin* handling can be migrated to use function attributes. See discussion on D61634 for background. This is an enabler for fixing handling of these options for LTO, for example. This change should not affect behavior, as the provided function is not yet used to build a specifically per-function TLI, but rather enables that migration. Most of the changes were very mechanical, e.g. passing a Function to the legacy analysis pass's getTLI interface, or in Module level cases, adding a callback. This is similar to the way the per-function TTI analysis works. There was one place where we were looking for builtins but not in the context of a specific function. See FindCXAAtExit in lib/Transforms/IPO/GlobalOpt.cpp. I'm somewhat concerned my workaround could provide the wrong behavior in some corner cases. Suggestions welcome. Reviewers: chandlerc, hfinkel Subscribers: arsenm, dschuff, jvesely, nhaehnle, mehdi_amini, javed.absar, sbc100, jgravelle-google, eraman, aheejin, steven_wu, george.burgess.iv, dexonsmith, jfb, asbirlea, gchatelet, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D66428 llvm-svn: 371284
2019-09-07 11:09:36 +08:00
; CHECK-O1-NEXT: Running analysis: TargetLibraryAnalysis
[PM] Flesh out the new pass manager LTO pipeline. Differential Revision: https://reviews.llvm.org/D28996 llvm-svn: 292863
2017-01-24 08:57:39 +08:00
; CHECK-O-NEXT: Running analysis: FunctionAnalysisManagerCGSCCProxy
[PM] Try to make all three compilers happy when it comes to pretty printing. Modeled after a similar change from Michael Kuperstein. Let's hope this sticks together. llvm-svn: 292872
2017-01-24 09:45:53 +08:00
; CHECK-O-NEXT: Running analysis: OuterAnalysisManagerProxy<{{.*}}LazyCallGraph{{.*}}>
[NewPM][PassInstrument] Add PrintPass callback to StandardInstrumentations Problem: Right now, our "Running pass" is not accurate when passes are wrapped in adaptor because adaptor is never skipped and a pass could be skipped. The other problem is that "Running pass" for a adaptor is before any "Running pass" of passes/analyses it depends on. (for example, FunctionToLoopPassAdaptor). So the order of printing is not the actual order. Solution: Doing things like PassManager::Debuglogging is very intrusive because we need to specify Debuglogging whenever adaptor is created. (Actually, right now we're not specifying Debuglogging for some sub-PassManagers. Check PassBuilder) This patch move debug logging for pass as a PassInstrument callback. We could be sure that all running passes are logged and in the correct order. This could also be used to implement hierarchy pass logging in legacy PM. We could also move logging of pass manager to this if we want. The test fixes looks messy. It includes changes: - Remove PassInstrumentationAnalysis - Remove PassAdaptor - If a PassAdaptor is for a real pass, the pass is added - Pass reorder (to the correct order), related to PassAdaptor - Add missing passes (due to Debuglogging not passed down) Reviewed By: asbirlea, aeubanks Differential Revision: https://reviews.llvm.org/D84774
2020-07-29 08:08:24 +08:00
; CHECK-O-NEXT: Running pass: PostOrderFunctionAttrsPass
[PM] Flesh out the new pass manager LTO pipeline. Differential Revision: https://reviews.llvm.org/D28996 llvm-svn: 292863
2017-01-24 08:57:39 +08:00
; CHECK-O-NEXT: Running analysis: AAManager
[NewPM][opt] Run the "default" AA pipeline by default We tend to assume that the AA pipeline is by default the default AA pipeline and it's confusing when it's empty instead. PR48779 Initially reverted due to BasicAA running analyses in an unspecified order (multiple function calls as parameters), fixed by fetching analyses before the call to construct BasicAA. Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D95117
2021-01-21 08:53:03 +08:00
; CHECK-O-NEXT: Running analysis: BasicAA
; CHECK-O1-NEXT: Running analysis: AssumptionAnalysis on foo
; CHECK-O1-NEXT: Running analysis: DominatorTreeAnalysis
; CHECK-O-NEXT: Running analysis: ScopedNoAliasAA
; CHECK-O-NEXT: Running analysis: TypeBasedAA
; CHECK-O-NEXT: Running analysis: OuterAnalysisManagerProxy
[PM] Flesh out the new pass manager LTO pipeline. Differential Revision: https://reviews.llvm.org/D28996 llvm-svn: 292863
2017-01-24 08:57:39 +08:00
; CHECK-O-NEXT: Running pass: ReversePostOrderFunctionAttrsPass
; CHECK-O-NEXT: Running analysis: CallGraphAnalysis
; CHECK-O-NEXT: Running pass: GlobalSplitPass
; CHECK-O-NEXT: Running pass: WholeProgramDevirtPass
[ThinLTO] Enable ThinLTO WholeProgramDevirt and LowerTypeTests in new PM Summary: Enable these passes for CFI and WPD in ThinLTO and LTO with the new pass manager. Add a couple of tests for both PMs based on the clang tests tools/clang/test/CodeGen/thinlto-distributed-cfi*.ll, but just test through llvm-lto2 and not with distributed ThinLTO. Reviewers: pcc Subscribers: mehdi_amini, inglorion, eraman, steven_wu, dexonsmith, llvm-commits Differential Revision: https://reviews.llvm.org/D49429 llvm-svn: 337461
2018-07-19 22:51:32 +08:00
; CHECK-O1-NEXT: Running pass: LowerTypeTestsPass
[NPM][LTO] Update buildLTODefaultPipeline to be more in-line with the old pass manager The NPM LTO pipeline has a lot of fixme's and missing passes, causing a lot of regressions after the switch in c70737b. Notably unrolling and vectorization were both disabled, but many other passes are missing compared to the old pass manager. This attempt to enable the most obvious missing passes like the unroller, vectorization and other loop passes, fixing the existing FIXME comments. Differential Revision: https://reviews.llvm.org/D96780
2021-02-18 00:56:28 +08:00
; CHECK-O23SZ-NEXT: Running pass: GlobalOptPass
; CHECK-O23SZ-NEXT: Running pass: PromotePass
; CHECK-O23SZ-NEXT: Running pass: ConstantMergePass
; CHECK-O23SZ-NEXT: Running pass: DeadArgumentEliminationPass
Another try to commit 323321 (aggressive instruction combine). llvm-svn: 323416
2018-01-25 20:06:32 +08:00
; CHECK-O3-NEXT: Running pass: AggressiveInstCombinePass
[NPM][LTO] Update buildLTODefaultPipeline to be more in-line with the old pass manager The NPM LTO pipeline has a lot of fixme's and missing passes, causing a lot of regressions after the switch in c70737b. Notably unrolling and vectorization were both disabled, but many other passes are missing compared to the old pass manager. This attempt to enable the most obvious missing passes like the unroller, vectorization and other loop passes, fixing the existing FIXME comments. Differential Revision: https://reviews.llvm.org/D96780
2021-02-18 00:56:28 +08:00
; CHECK-O23SZ-NEXT: Running pass: InstCombinePass
[PM] Enable registration of out-of-tree passes with PassBuilder Summary: This patch adds a callback registration API to the PassBuilder, enabling registering out-of-tree passes with it. Through the Callback API, callers may register callbacks with the various stages at which passes are added into pass managers, including parsing of a pass pipeline as well as at extension points within the default -O pipelines. Registering utilities like `require<>` and `invalidate<>` needs to be handled manually by the caller, but a helper is provided. Additionally, adding passes at pipeline extension points is exposed through the opt tool. This patch adds a `-passes-ep-X` commandline option for every extension point X, which opt parses into pipelines inserted into that extension point. Reviewers: chandlerc Reviewed By: chandlerc Subscribers: lksbhm, grosser, davide, mehdi_amini, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D33464 llvm-svn: 307532
2017-07-10 18:57:55 +08:00
; CHECK-EP-Peephole-NEXT: Running pass: NoOpFunctionPass
[NPM][LTO] Update buildLTODefaultPipeline to be more in-line with the old pass manager The NPM LTO pipeline has a lot of fixme's and missing passes, causing a lot of regressions after the switch in c70737b. Notably unrolling and vectorization were both disabled, but many other passes are missing compared to the old pass manager. This attempt to enable the most obvious missing passes like the unroller, vectorization and other loop passes, fixing the existing FIXME comments. Differential Revision: https://reviews.llvm.org/D96780
2021-02-18 00:56:28 +08:00
; CHECK-O23SZ-NEXT: Running pass: ModuleInlinerWrapperPass
; CHECK-O23SZ-NEXT: Running analysis: InlineAdvisorAnalysis
; CHECK-O23SZ-NEXT: Running pass: InlinerPass
; CHECK-O23SZ-NEXT: Running pass: InlinerPass
; CHECK-O23SZ-NEXT: Running pass: GlobalOptPass
; CHECK-O23SZ-NEXT: Running pass: GlobalDCEPass
; CHECK-O23SZ-NEXT: Running pass: InstCombinePass
[PM] Enable registration of out-of-tree passes with PassBuilder Summary: This patch adds a callback registration API to the PassBuilder, enabling registering out-of-tree passes with it. Through the Callback API, callers may register callbacks with the various stages at which passes are added into pass managers, including parsing of a pass pipeline as well as at extension points within the default -O pipelines. Registering utilities like `require<>` and `invalidate<>` needs to be handled manually by the caller, but a helper is provided. Additionally, adding passes at pipeline extension points is exposed through the opt tool. This patch adds a `-passes-ep-X` commandline option for every extension point X, which opt parses into pipelines inserted into that extension point. Reviewers: chandlerc Reviewed By: chandlerc Subscribers: lksbhm, grosser, davide, mehdi_amini, llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D33464 llvm-svn: 307532
2017-07-10 18:57:55 +08:00
; CHECK-EP-Peephole-NEXT: Running pass: NoOpFunctionPass
[NPM][LTO] Update buildLTODefaultPipeline to be more in-line with the old pass manager The NPM LTO pipeline has a lot of fixme's and missing passes, causing a lot of regressions after the switch in c70737b. Notably unrolling and vectorization were both disabled, but many other passes are missing compared to the old pass manager. This attempt to enable the most obvious missing passes like the unroller, vectorization and other loop passes, fixing the existing FIXME comments. Differential Revision: https://reviews.llvm.org/D96780
2021-02-18 00:56:28 +08:00
; CHECK-O23SZ-NEXT: Running pass: JumpThreadingPass
; CHECK-O23SZ-NEXT: Running analysis: LazyValueAnalysis
; CHECK-O23SZ-NEXT: Running pass: SROA on foo
; CHECK-O23SZ-NEXT: Running pass: TailCallElimPass on foo
; CHECK-O23SZ-NEXT: Running pass: PostOrderFunctionAttrsPass on (foo)
; CHECK-O23SZ-NEXT: Running pass: LoopSimplifyPass on foo
; CHECK-O23SZ-NEXT: Running analysis: LoopAnalysis on foo
; CHECK-O23SZ-NEXT: Running pass: LCSSAPass on foo
[Passes] Use MemorySSA for LICM during LTO. Split off from D102345 to commit this separately from other changes in the patch. This aligns the behavior of the new PM with the legacy PM for LTO, with respect to running LICM. Together with the remaining changes in D102345, this fixes new PM regressions where we fail to vectorize loops that are vectorized with the legacy PM.
2021-05-13 18:59:41 +08:00
; CHECK-O23SZ-NEXT: Running analysis: MemorySSAAnalysis on foo
[NPM][LTO] Update buildLTODefaultPipeline to be more in-line with the old pass manager The NPM LTO pipeline has a lot of fixme's and missing passes, causing a lot of regressions after the switch in c70737b. Notably unrolling and vectorization were both disabled, but many other passes are missing compared to the old pass manager. This attempt to enable the most obvious missing passes like the unroller, vectorization and other loop passes, fixing the existing FIXME comments. Differential Revision: https://reviews.llvm.org/D96780
2021-02-18 00:56:28 +08:00
; CHECK-O23SZ-NEXT: Running analysis: ScalarEvolutionAnalysis on foo
; CHECK-O23SZ-NEXT: Running analysis: InnerAnalysisManagerProxy
; CHECK-O23SZ-NEXT: Running pass: LICMPass on Loop
; CHECK-O23SZ-NEXT: Running pass: GVN on foo
; CHECK-O23SZ-NEXT: Running analysis: MemoryDependenceAnalysis on foo
; CHECK-O23SZ-NEXT: Running analysis: PhiValuesAnalysis on foo
; CHECK-O23SZ-NEXT: Running pass: MemCpyOptPass on foo
[MemCopyOpt] Enable MemorySSA by default This enables use of MemorySSA instead of MemDep in MemCpyOpt. To allow this without significant compile-time impact, the MemCpyOpt pass is moved directly before DSE (in the cases where this was not already the case), which allows us to reuse the existing MemorySSA analysis. Unlike the MemDep-based implementation, the MemorySSA-based MemCpyOpt can also perform simple optimizations across basic blocks. Differential Revision: https://reviews.llvm.org/D94376
2021-01-10 17:52:01 +08:00
; CHECK-O23SZ-NEXT: Running pass: DSEPass on foo
[NPM][LTO] Update buildLTODefaultPipeline to be more in-line with the old pass manager The NPM LTO pipeline has a lot of fixme's and missing passes, causing a lot of regressions after the switch in c70737b. Notably unrolling and vectorization were both disabled, but many other passes are missing compared to the old pass manager. This attempt to enable the most obvious missing passes like the unroller, vectorization and other loop passes, fixing the existing FIXME comments. Differential Revision: https://reviews.llvm.org/D96780
2021-02-18 00:56:28 +08:00
; CHECK-O23SZ-NEXT: Running analysis: PostDominatorTreeAnalysis on foo
; CHECK-O23SZ-NEXT: Running pass: MergedLoadStoreMotionPass on foo
; CHECK-O23SZ-NEXT: Running pass: LoopSimplifyPass on foo
; CHECK-O23SZ-NEXT: Running pass: LCSSAPass on foo
; CHECK-O23SZ-NEXT: Running pass: IndVarSimplifyPass on Loop
; CHECK-O23SZ-NEXT: Running pass: LoopDeletionPass on Loop
; CHECK-O23SZ-NEXT: Running pass: LoopFullUnrollPass on Loop
; CHECK-O23SZ-NEXT: Running pass: LoopDistributePass on foo
; CHECK-O23SZ-NEXT: Running pass: LoopVectorizePass on foo
; CHECK-O23SZ-NEXT: Running analysis: BlockFrequencyAnalysis on foo
; CHECK-O23SZ-NEXT: Running analysis: BranchProbabilityAnalysis on foo
; CHECK-O23SZ-NEXT: Running analysis: DemandedBitsAnalysis on foo
; CHECK-O23SZ-NEXT: Running pass: LoopUnrollPass on foo
; CHECK-O23SZ-NEXT: WarnMissedTransformationsPass on foo
; CHECK-O23SZ-NEXT: Running pass: InstCombinePass on foo
; CHECK-O23SZ-NEXT: Running pass: SimplifyCFGPass on foo
; CHECK-O23SZ-NEXT: Running pass: SCCPPass on foo
; CHECK-O23SZ-NEXT: Running pass: InstCombinePass on foo
; CHECK-O23SZ-NEXT: Running pass: BDCEPass on foo
; CHECK-O2-NEXT: Running pass: SLPVectorizerPass on foo
; CHECK-O3-NEXT: Running pass: SLPVectorizerPass on foo
; CHECK-OS-NEXT: Running pass: SLPVectorizerPass on foo
; CHECK-O23SZ-NEXT: Running pass: VectorCombinePass on foo
; CHECK-O23SZ-NEXT: Running pass: AlignmentFromAssumptionsPass on foo
; CHECK-O23SZ-NEXT: Running pass: InstCombinePass on foo
; CHECK-EP-Peephole-NEXT: Running pass: NoOpFunctionPass on foo
; CHECK-O23SZ-NEXT: Running pass: JumpThreadingPass on foo
; CHECK-O23SZ-NEXT: Running pass: CrossDSOCFIPass
; CHECK-O23SZ-NEXT: Running pass: LowerTypeTestsPass
Restore "[WPD/LowerTypeTests] Delay lowering/removal of type tests until after ICP" This restores commit 80d0a137a5aba6998fadb764f1e11cb901aae233, and the follow on fix in 873c0d0786dcf22f4af39f65df824917f70f2170, with a new fix for test failures after a 2-stage clang bootstrap, and a more robust fix for the Chromium build failure that an earlier version partially fixed. See also discussion on D75201. Reviewers: evgeny777 Subscribers: mehdi_amini, Prazek, hiraditya, steven_wu, dexonsmith, arphaman, davidxl, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D73242
2020-03-18 02:08:35 +08:00
; CHECK-O-NEXT: Running pass: LowerTypeTestsPass
[NPM][LTO] Update buildLTODefaultPipeline to be more in-line with the old pass manager The NPM LTO pipeline has a lot of fixme's and missing passes, causing a lot of regressions after the switch in c70737b. Notably unrolling and vectorization were both disabled, but many other passes are missing compared to the old pass manager. This attempt to enable the most obvious missing passes like the unroller, vectorization and other loop passes, fixing the existing FIXME comments. Differential Revision: https://reviews.llvm.org/D96780
2021-02-18 00:56:28 +08:00
; CHECK-O23SZ-NEXT: Running pass: SimplifyCFGPass
; CHECK-O23SZ-NEXT: Running pass: EliminateAvailableExternallyPass
; CHECK-O23SZ-NEXT: Running pass: GlobalDCEPass
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 17:46:55 +08:00
; CHECK-O-NEXT: Running pass: AnnotationRemarksPass on foo
[PM] Flesh out the new pass manager LTO pipeline. Differential Revision: https://reviews.llvm.org/D28996 llvm-svn: 292863
2017-01-24 08:57:39 +08:00
; CHECK-O-NEXT: Running pass: PrintModulePass
; Make sure we get the IR back out without changes when we print the module.
; CHECK-O-LABEL: define void @foo(i32 %n) local_unnamed_addr {
; CHECK-O-NEXT: entry:
; CHECK-O-NEXT: br label %loop
; CHECK-O: loop:
; CHECK-O-NEXT: %iv = phi i32 [ 0, %entry ], [ %iv.next, %loop ]
; CHECK-O-NEXT: %iv.next = add i32 %iv, 1
; CHECK-O-NEXT: tail call void @bar()
; CHECK-O-NEXT: %cmp = icmp eq i32 %iv, %n
; CHECK-O-NEXT: br i1 %cmp, label %exit, label %loop
; CHECK-O: exit:
; CHECK-O-NEXT: ret void
; CHECK-O-NEXT: }
;
declare void @bar() local_unnamed_addr
define void @foo(i32 %n) local_unnamed_addr {
entry:
br label %loop
loop:
%iv = phi i32 [ 0, %entry ], [ %iv.next, %loop ]
%iv.next = add i32 %iv, 1
tail call void @bar()
%cmp = icmp eq i32 %iv, %n
br i1 %cmp, label %exit, label %loop
exit:
ret void
}