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.

180 lines
9.5 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] Only invalidate modified functions' analyses in CGSCC passes + turn on eagerly invalidate analyses Previously, any change in any function in an SCC would cause all analyses for all functions in the SCC to be invalidated. With this change, we now manually invalidate analyses for functions we modify, then let the pass manager know that all function analyses should be preserved since we've already handled function analysis invalidation. So far this only touches the inliner, argpromotion, function-attrs, and updateCGAndAnalysisManager(), since they are the most used. This is part of an effort to investigate running the function simplification pipeline less on functions we visit multiple times in the inliner pipeline. However, this causes major memory regressions especially on larger IR. To counteract this, turn on the option to eagerly invalidate function analyses. This invalidates analyses on functions immediately after they're processed in a module or scc to function adaptor for specific parts of the pipeline. Within an SCC, if a pass only modifies one function, other functions in the SCC do not have their analyses invalidated, so in later function passes in the SCC pass manager the analyses may still be cached. It is only after the function passes that the eager invalidation takes effect. For the default pipelines this makes sense because the inliner pipeline runs the function simplification pipeline after all other SCC passes (except CoroSplit which doesn't request any analyses). Overall this has mostly positive effects on compile time and positive effects on memory usage. https://llvm-compile-time-tracker.com/compare.php?from=7f627596977624730f9298a1b69883af1555765e&to=39e824e0d3ca8a517502f13032dfa67304841c90&stat=instructions https://llvm-compile-time-tracker.com/compare.php?from=7f627596977624730f9298a1b69883af1555765e&to=39e824e0d3ca8a517502f13032dfa67304841c90&stat=max-rss D113196 shows that we slightly regressed compile times in exchange for some memory improvements when turning on eager invalidation. D100917 shows that we slightly improved compile times in exchange for major memory regressions in some cases when invalidating less in SCC passes. Turning these on at the same time keeps the memory improvements while keeping compile times neutral/slightly positive. Reviewed By: asbirlea, nikic Differential Revision: https://reviews.llvm.org/D113304
2021-05-04 07:50:26 +08:00
; RUN: opt -disable-verify -verify-cfg-preserved=0 -eagerly-invalidate-analyses=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] Only invalidate modified functions' analyses in CGSCC passes + turn on eagerly invalidate analyses Previously, any change in any function in an SCC would cause all analyses for all functions in the SCC to be invalidated. With this change, we now manually invalidate analyses for functions we modify, then let the pass manager know that all function analyses should be preserved since we've already handled function analysis invalidation. So far this only touches the inliner, argpromotion, function-attrs, and updateCGAndAnalysisManager(), since they are the most used. This is part of an effort to investigate running the function simplification pipeline less on functions we visit multiple times in the inliner pipeline. However, this causes major memory regressions especially on larger IR. To counteract this, turn on the option to eagerly invalidate function analyses. This invalidates analyses on functions immediately after they're processed in a module or scc to function adaptor for specific parts of the pipeline. Within an SCC, if a pass only modifies one function, other functions in the SCC do not have their analyses invalidated, so in later function passes in the SCC pass manager the analyses may still be cached. It is only after the function passes that the eager invalidation takes effect. For the default pipelines this makes sense because the inliner pipeline runs the function simplification pipeline after all other SCC passes (except CoroSplit which doesn't request any analyses). Overall this has mostly positive effects on compile time and positive effects on memory usage. https://llvm-compile-time-tracker.com/compare.php?from=7f627596977624730f9298a1b69883af1555765e&to=39e824e0d3ca8a517502f13032dfa67304841c90&stat=instructions https://llvm-compile-time-tracker.com/compare.php?from=7f627596977624730f9298a1b69883af1555765e&to=39e824e0d3ca8a517502f13032dfa67304841c90&stat=max-rss D113196 shows that we slightly regressed compile times in exchange for some memory improvements when turning on eager invalidation. D100917 shows that we slightly improved compile times in exchange for major memory regressions in some cases when invalidating less in SCC passes. Turning these on at the same time keeps the memory improvements while keeping compile times neutral/slightly positive. Reviewed By: asbirlea, nikic Differential Revision: https://reviews.llvm.org/D113304
2021-05-04 07:50:26 +08:00
; RUN: opt -disable-verify -verify-cfg-preserved=0 -eagerly-invalidate-analyses=0 -debug-pass-manager \
[NewPM] Add extension points to LTO pipeline in PassBuilder This PR adds two extension points to the default LTO pipeline in PassBuilder, one at the beginning and one at the end. These two extension points already existed in the old pass manager, the aim is to replicate the same functionality in the new one. Reviewed By: aeubanks Differential Revision: https://reviews.llvm.org/D120491
2022-02-26 04:02:37 +08:00
; RUN: -passes='lto<O1>' -S %s -passes-ep-full-link-time-optimization-early=no-op-module \
; RUN: -passes-ep-full-link-time-optimization-last=no-op-module 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-O --check-prefix=CHECK-O1 --check-prefix=CHECK-EP
; RUN: opt -disable-verify -verify-cfg-preserved=0 -eagerly-invalidate-analyses=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] Only invalidate modified functions' analyses in CGSCC passes + turn on eagerly invalidate analyses Previously, any change in any function in an SCC would cause all analyses for all functions in the SCC to be invalidated. With this change, we now manually invalidate analyses for functions we modify, then let the pass manager know that all function analyses should be preserved since we've already handled function analysis invalidation. So far this only touches the inliner, argpromotion, function-attrs, and updateCGAndAnalysisManager(), since they are the most used. This is part of an effort to investigate running the function simplification pipeline less on functions we visit multiple times in the inliner pipeline. However, this causes major memory regressions especially on larger IR. To counteract this, turn on the option to eagerly invalidate function analyses. This invalidates analyses on functions immediately after they're processed in a module or scc to function adaptor for specific parts of the pipeline. Within an SCC, if a pass only modifies one function, other functions in the SCC do not have their analyses invalidated, so in later function passes in the SCC pass manager the analyses may still be cached. It is only after the function passes that the eager invalidation takes effect. For the default pipelines this makes sense because the inliner pipeline runs the function simplification pipeline after all other SCC passes (except CoroSplit which doesn't request any analyses). Overall this has mostly positive effects on compile time and positive effects on memory usage. https://llvm-compile-time-tracker.com/compare.php?from=7f627596977624730f9298a1b69883af1555765e&to=39e824e0d3ca8a517502f13032dfa67304841c90&stat=instructions https://llvm-compile-time-tracker.com/compare.php?from=7f627596977624730f9298a1b69883af1555765e&to=39e824e0d3ca8a517502f13032dfa67304841c90&stat=max-rss D113196 shows that we slightly regressed compile times in exchange for some memory improvements when turning on eager invalidation. D100917 shows that we slightly improved compile times in exchange for major memory regressions in some cases when invalidating less in SCC passes. Turning these on at the same time keeps the memory improvements while keeping compile times neutral/slightly positive. Reviewed By: asbirlea, nikic Differential Revision: https://reviews.llvm.org/D113304
2021-05-04 07:50:26 +08:00
; RUN: opt -disable-verify -verify-cfg-preserved=0 -eagerly-invalidate-analyses=0 -debug-pass-manager \
[NewPM] Add extension points to LTO pipeline in PassBuilder This PR adds two extension points to the default LTO pipeline in PassBuilder, one at the beginning and one at the end. These two extension points already existed in the old pass manager, the aim is to replicate the same functionality in the new one. Reviewed By: aeubanks Differential Revision: https://reviews.llvm.org/D120491
2022-02-26 04:02:37 +08:00
; RUN: -passes='lto<O2>' -S %s -passes-ep-full-link-time-optimization-early=no-op-module \
; RUN: -passes-ep-full-link-time-optimization-last=no-op-module 2>&1 \
; RUN: | FileCheck %s --check-prefix=CHECK-O --check-prefix=CHECK-O23SZ \
; RUN: --check-prefix=CHECK-O2 --check-prefix=CHECK-EP
; RUN: opt -disable-verify -verify-cfg-preserved=0 -eagerly-invalidate-analyses=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] Only invalidate modified functions' analyses in CGSCC passes + turn on eagerly invalidate analyses Previously, any change in any function in an SCC would cause all analyses for all functions in the SCC to be invalidated. With this change, we now manually invalidate analyses for functions we modify, then let the pass manager know that all function analyses should be preserved since we've already handled function analysis invalidation. So far this only touches the inliner, argpromotion, function-attrs, and updateCGAndAnalysisManager(), since they are the most used. This is part of an effort to investigate running the function simplification pipeline less on functions we visit multiple times in the inliner pipeline. However, this causes major memory regressions especially on larger IR. To counteract this, turn on the option to eagerly invalidate function analyses. This invalidates analyses on functions immediately after they're processed in a module or scc to function adaptor for specific parts of the pipeline. Within an SCC, if a pass only modifies one function, other functions in the SCC do not have their analyses invalidated, so in later function passes in the SCC pass manager the analyses may still be cached. It is only after the function passes that the eager invalidation takes effect. For the default pipelines this makes sense because the inliner pipeline runs the function simplification pipeline after all other SCC passes (except CoroSplit which doesn't request any analyses). Overall this has mostly positive effects on compile time and positive effects on memory usage. https://llvm-compile-time-tracker.com/compare.php?from=7f627596977624730f9298a1b69883af1555765e&to=39e824e0d3ca8a517502f13032dfa67304841c90&stat=instructions https://llvm-compile-time-tracker.com/compare.php?from=7f627596977624730f9298a1b69883af1555765e&to=39e824e0d3ca8a517502f13032dfa67304841c90&stat=max-rss D113196 shows that we slightly regressed compile times in exchange for some memory improvements when turning on eager invalidation. D100917 shows that we slightly improved compile times in exchange for major memory regressions in some cases when invalidating less in SCC passes. Turning these on at the same time keeps the memory improvements while keeping compile times neutral/slightly positive. Reviewed By: asbirlea, nikic Differential Revision: https://reviews.llvm.org/D113304
2021-05-04 07:50:26 +08:00
; RUN: opt -disable-verify -verify-cfg-preserved=0 -eagerly-invalidate-analyses=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] Only invalidate modified functions' analyses in CGSCC passes + turn on eagerly invalidate analyses Previously, any change in any function in an SCC would cause all analyses for all functions in the SCC to be invalidated. With this change, we now manually invalidate analyses for functions we modify, then let the pass manager know that all function analyses should be preserved since we've already handled function analysis invalidation. So far this only touches the inliner, argpromotion, function-attrs, and updateCGAndAnalysisManager(), since they are the most used. This is part of an effort to investigate running the function simplification pipeline less on functions we visit multiple times in the inliner pipeline. However, this causes major memory regressions especially on larger IR. To counteract this, turn on the option to eagerly invalidate function analyses. This invalidates analyses on functions immediately after they're processed in a module or scc to function adaptor for specific parts of the pipeline. Within an SCC, if a pass only modifies one function, other functions in the SCC do not have their analyses invalidated, so in later function passes in the SCC pass manager the analyses may still be cached. It is only after the function passes that the eager invalidation takes effect. For the default pipelines this makes sense because the inliner pipeline runs the function simplification pipeline after all other SCC passes (except CoroSplit which doesn't request any analyses). Overall this has mostly positive effects on compile time and positive effects on memory usage. https://llvm-compile-time-tracker.com/compare.php?from=7f627596977624730f9298a1b69883af1555765e&to=39e824e0d3ca8a517502f13032dfa67304841c90&stat=instructions https://llvm-compile-time-tracker.com/compare.php?from=7f627596977624730f9298a1b69883af1555765e&to=39e824e0d3ca8a517502f13032dfa67304841c90&stat=max-rss D113196 shows that we slightly regressed compile times in exchange for some memory improvements when turning on eager invalidation. D100917 shows that we slightly improved compile times in exchange for major memory regressions in some cases when invalidating less in SCC passes. Turning these on at the same time keeps the memory improvements while keeping compile times neutral/slightly positive. Reviewed By: asbirlea, nikic Differential Revision: https://reviews.llvm.org/D113304
2021-05-04 07:50:26 +08:00
; RUN: opt -disable-verify -verify-cfg-preserved=0 -eagerly-invalidate-analyses=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] Only invalidate modified functions' analyses in CGSCC passes + turn on eagerly invalidate analyses Previously, any change in any function in an SCC would cause all analyses for all functions in the SCC to be invalidated. With this change, we now manually invalidate analyses for functions we modify, then let the pass manager know that all function analyses should be preserved since we've already handled function analysis invalidation. So far this only touches the inliner, argpromotion, function-attrs, and updateCGAndAnalysisManager(), since they are the most used. This is part of an effort to investigate running the function simplification pipeline less on functions we visit multiple times in the inliner pipeline. However, this causes major memory regressions especially on larger IR. To counteract this, turn on the option to eagerly invalidate function analyses. This invalidates analyses on functions immediately after they're processed in a module or scc to function adaptor for specific parts of the pipeline. Within an SCC, if a pass only modifies one function, other functions in the SCC do not have their analyses invalidated, so in later function passes in the SCC pass manager the analyses may still be cached. It is only after the function passes that the eager invalidation takes effect. For the default pipelines this makes sense because the inliner pipeline runs the function simplification pipeline after all other SCC passes (except CoroSplit which doesn't request any analyses). Overall this has mostly positive effects on compile time and positive effects on memory usage. https://llvm-compile-time-tracker.com/compare.php?from=7f627596977624730f9298a1b69883af1555765e&to=39e824e0d3ca8a517502f13032dfa67304841c90&stat=instructions https://llvm-compile-time-tracker.com/compare.php?from=7f627596977624730f9298a1b69883af1555765e&to=39e824e0d3ca8a517502f13032dfa67304841c90&stat=max-rss D113196 shows that we slightly regressed compile times in exchange for some memory improvements when turning on eager invalidation. D100917 shows that we slightly improved compile times in exchange for major memory regressions in some cases when invalidating less in SCC passes. Turning these on at the same time keeps the memory improvements while keeping compile times neutral/slightly positive. Reviewed By: asbirlea, nikic Differential Revision: https://reviews.llvm.org/D113304
2021-05-04 07:50:26 +08:00
; RUN: opt -disable-verify -verify-cfg-preserved=0 -eagerly-invalidate-analyses=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
[NewPM] Add extension points to LTO pipeline in PassBuilder This PR adds two extension points to the default LTO pipeline in PassBuilder, one at the beginning and one at the end. These two extension points already existed in the old pass manager, the aim is to replicate the same functionality in the new one. Reviewed By: aeubanks Differential Revision: https://reviews.llvm.org/D120491
2022-02-26 04:02:37 +08:00
; CHECK-EP-NEXT: Running pass: NoOpModulePass
[NewPM] Add CrossDSOCFI pass irrespective of LTO optimization level This pass is not an optimization and is needed for CFI functionality (cross-dso verification). Differential Revision: https://reviews.llvm.org/D106699
2021-07-24 03:16:22 +08:00
; CHECK-O-NEXT: Running pass: CrossDSOCFIPass
[PassBuilder] Add OpenMPOpt to default LTO pipeline The LTO support for OpenMP offloading allows us to run the OpenMPOpt pass during the LTO pipeline. This patch introduces an early run of the Module pass and a late run of the CGSCC pass. These are quick no-ops if there is no OpenMP in the module. Depends on D118198 Differential Revision: https://reviews.llvm.org/D118611
2022-01-22 04:43:20 +08:00
; CHECK-O-NEXT: Running pass: OpenMPOptPass
[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
[InferAddressSpaces] Support assumed addrspaces from addrspace predicates. - CUDA cannot associate memory space with pointer types. Even though Clang could add extra attributes to specify the address space explicitly on a pointer type, it breaks the portability between Clang and NVCC. - This change proposes to assume the address space from a pointer from the assumption built upon target-specific address space predicates, such as `__isGlobal` from CUDA. E.g., ``` foo(float *p) { __builtin_assume(__isGlobal(p)); // From there, we could assume p is a global pointer instead of a // generic one. } ``` This makes the code portable without introducing the implementation-specific features. Note that NVCC starts to support __builtin_assume from version 11. Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D112041
2021-10-15 11:41:16 +08:00
; CHECK-O1-NEXT: Running analysis: TargetIRAnalysis
[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-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
; CHECK-O23SZ-NEXT: Running pass: InstCombinePass
[Passes] Move AggressiveInstCombine after InstCombine Swap AIC and IC neighbouring in pipeline. This looks more natural and even almost has no effect for now (three slightly touched tests of test-suite). Also this could be the first step towards merging AIC (or its part) to -O2 pipeline. After several changes in AIC (like D108091, D108201, D107766, D109515, D109236) there've been observed several regressions (like PR52078, PR52253, PR52289) that were fixed in different passes (see D111330, D112721) by extending their functionality, but these regressions were exposed since changed AIC prevents IC from making some of early optimizations. This is common problem and it should be fixed by just moving AIC after IC which looks more logically by itself: make aggressive instruction combining only after failed ordinary one. Fixes PR52289 Reviewed By: spatel, RKSimon Differential Revision: https://reviews.llvm.org/D113179
2021-11-01 21:48:52 +08:00
; CHECK-O3-NEXT: Running pass: AggressiveInstCombinePass
[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
[Inline] Make sure the InlineAdvisor is correctly cleared. If another inlining session came after a ModuleInlinerWrapperPass, the advisor alanysis would still be cached, but its Result would be cleared. We need to clear both. This addresses PR52118 Differential Revision: https://reviews.llvm.org/D111586
2021-10-12 07:43:28 +08:00
; CHECK-O23SZ-NEXT: Invalidating analysis: InlineAdvisorAnalysis
[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: GlobalDCEPass
[NewPM] Add missing LTO ArgPromotion pass This is a followup to D96780 to add one more pass missing from the NewPM LTO pipeline. The missing ArgPromotion run is inserted at the same position as in the LegacyPM, resolving the already present FIXME: https://github.com/llvm/llvm-project/blob/16086d47c0d0cd08ffae8e69a69c88653e654d01/llvm/lib/Transforms/IPO/PassManagerBuilder.cpp#L1096-L1098 The compile-time impact is minimal with ~0.1% geomean regression on CTMark. Differential Revision: https://reviews.llvm.org/D108866
2021-08-28 18:25:58 +08:00
; CHECK-O23SZ-NEXT: Running pass: ArgumentPromotionPass
[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: JumpThreadingPass
; CHECK-O23SZ-NEXT: Running analysis: LazyValueAnalysis
[NFC] Rename GVN -> GVNPass and SROA -> SROAPass To be more consistent with other pass struct names. There are still more passes that don't end with "Pass", but these are the important ones. Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D112935
2021-11-01 23:56:48 +08:00
; CHECK-O23SZ-NEXT: Running pass: SROAPass 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 pass: TailCallElimPass on foo
; CHECK-O23SZ-NEXT: Running pass: PostOrderFunctionAttrsPass on (foo)
[Passes] Use regex to match GlobalsAA line in test. On some platforms/compiler combinations, it appears the output is slightly different. Update the test to use a regex, as is done at other places in the new-pm-*default.ll tests to address buildbot failures.
2021-05-13 20:22:18 +08:00
; CHECK-O23SZ-NEXT: Running pass: RequireAnalysisPass<{{.*}}GlobalsAA
[Passes] Run GlobalsAA before LICM during LTO in new PM. This patch adjusts the LTO pipeline in the new PM to run GlobalsAA before LICM to match the legacy PM. This fixes a regression where the new PM failed to vectorize loops that require hoisting/sinking by LICM depending on GlobalsAA info. Reviewed By: aeubanks Differential Revision: https://reviews.llvm.org/D102345
2021-05-13 19:53:05 +08:00
; CHECK-O23SZ-NEXT: Running analysis: GlobalsAA on [module]
[test] Fix new-pm-lto-defaults.ll to work on all platforms https://lab.llvm.org/buildbot/#/builders/119/builds/3775/steps/8/logs/FAIL__LLVM__new-pm-lto-defaults_ll Followup to D102345.
2021-05-14 09:12:55 +08:00
; CHECK-O23SZ-NEXT: Running pass: InvalidateAnalysisPass<{{.*}}AAManager
[Passes] Run GlobalsAA before LICM during LTO in new PM. This patch adjusts the LTO pipeline in the new PM to run GlobalsAA before LICM to match the legacy PM. This fixes a regression where the new PM failed to vectorize loops that require hoisting/sinking by LICM depending on GlobalsAA info. Reviewed By: aeubanks Differential Revision: https://reviews.llvm.org/D102345
2021-05-13 19:53:05 +08:00
; CHECK-O23SZ-NEXT: Invalidating analysis: AAManager on foo
[PassBuilder] Add OpenMPOpt to default LTO pipeline The LTO support for OpenMP offloading allows us to run the OpenMPOpt pass during the LTO pipeline. This patch introduces an early run of the Module pass and a late run of the CGSCC pass. These are quick no-ops if there is no OpenMP in the module. Depends on D118198 Differential Revision: https://reviews.llvm.org/D118611
2022-01-22 04:43:20 +08:00
; CHECK-O23SZ-NEXT: Running pass: OpenMPOptCGSCCPass 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 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
[Passes] Run GlobalsAA before LICM during LTO in new PM. This patch adjusts the LTO pipeline in the new PM to run GlobalsAA before LICM to match the legacy PM. This fixes a regression where the new PM failed to vectorize loops that require hoisting/sinking by LICM depending on GlobalsAA info. Reviewed By: aeubanks Differential Revision: https://reviews.llvm.org/D102345
2021-05-13 19:53:05 +08:00
; CHECK-O23SZ-NEXT: Running analysis: AAManager 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
[NFC] Rename GVN -> GVNPass and SROA -> SROAPass To be more consistent with other pass struct names. There are still more passes that don't end with "Pass", but these are the important ones. Reviewed By: asbirlea Differential Revision: https://reviews.llvm.org/D112935
2021-11-01 23:56:48 +08:00
; CHECK-O23SZ-NEXT: Running pass: GVNPass 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: 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: 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
[NewPM] Add extension points to LTO pipeline in PassBuilder This PR adds two extension points to the default LTO pipeline in PassBuilder, one at the beginning and one at the end. These two extension points already existed in the old pass manager, the aim is to replicate the same functionality in the new one. Reviewed By: aeubanks Differential Revision: https://reviews.llvm.org/D120491
2022-02-26 04:02:37 +08:00
; CHECK-EP-NEXT: Running pass: NoOpModulePass
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
}