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-thinlto-prelink-samp...

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

215 lines
11 KiB
LLVM
Raw Normal View History

Restore "[ThinLTO] Add additional ThinLTO pipeline testing with new PM" This restores 2af97be8027a0823b88d4b6a07fc5eedb440bc1f (reverted at 6288f86e870c7bb7fe47cc138320b9eb34c93941), with all the fixes I had applied at the time, along with a new fix for non-determinism in the ordering of a couple of passes due to being accessed as parameters on the same call. I've also added --dump-input=fail to the new tests so I can more thoroughly fix any additional failures.
2020-01-14 03:09:13 +08:00
; Validate ThinLTO prelink pipeline when we have Sample PGO
;
; RUN: opt -disable-verify -debug-pass-manager \
; RUN: -pgo-kind=pgo-sample-use-pipeline -profile-file='%S/Inputs/new-pm-thinlto-samplepgo-defaults.prof' \
[NPM] Move more O0 pass building into PassBuilder This moves handling of alwaysinline, coroutines, matrix lowering, PGO, and LTO-required passes into PassBuilder. Much of this is replicated between Clang and opt. Other out-of-tree users also replicate some of this, such as Rust [1] replicating the alwaysinline, LTO, and PGO passes. The LTO passes are also now run in build(Thin)LTOPreLinkDefaultPipeline() since they are semantically required for (Thin)LTO. [1]: https://github.com/rust-lang/rust/blob/f5230fbf76bafd86ee4376a0e26e551df8d17fec/compiler/rustc_llvm/llvm-wrapper/PassWrapper.cpp#L896 Reviewed By: tejohnson Differential Revision: https://reviews.llvm.org/D91585
2020-11-17 04:48:42 +08:00
; RUN: -passes='thinlto-pre-link<O1>' -S %s 2>&1 \
[test] Fix unused check prefixes in test/Linker/ and test/Other/
2020-10-30 12:54:45 +08:00
; RUN: | FileCheck %s --check-prefixes=CHECK-O,CHECK-O1
Restore "[ThinLTO] Add additional ThinLTO pipeline testing with new PM" This restores 2af97be8027a0823b88d4b6a07fc5eedb440bc1f (reverted at 6288f86e870c7bb7fe47cc138320b9eb34c93941), with all the fixes I had applied at the time, along with a new fix for non-determinism in the ordering of a couple of passes due to being accessed as parameters on the same call. I've also added --dump-input=fail to the new tests so I can more thoroughly fix any additional failures.
2020-01-14 03:09:13 +08:00
; RUN: opt -disable-verify -debug-pass-manager \
; RUN: -pgo-kind=pgo-sample-use-pipeline -profile-file='%S/Inputs/new-pm-thinlto-samplepgo-defaults.prof' \
[NPM] Move more O0 pass building into PassBuilder This moves handling of alwaysinline, coroutines, matrix lowering, PGO, and LTO-required passes into PassBuilder. Much of this is replicated between Clang and opt. Other out-of-tree users also replicate some of this, such as Rust [1] replicating the alwaysinline, LTO, and PGO passes. The LTO passes are also now run in build(Thin)LTOPreLinkDefaultPipeline() since they are semantically required for (Thin)LTO. [1]: https://github.com/rust-lang/rust/blob/f5230fbf76bafd86ee4376a0e26e551df8d17fec/compiler/rustc_llvm/llvm-wrapper/PassWrapper.cpp#L896 Reviewed By: tejohnson Differential Revision: https://reviews.llvm.org/D91585
2020-11-17 04:48:42 +08:00
; RUN: -passes='thinlto-pre-link<O2>' -S %s 2>&1 \
[test] Fix unused check prefixes in test/Linker/ and test/Other/
2020-10-30 12:54:45 +08:00
; RUN: | FileCheck %s --check-prefixes=CHECK-O,CHECK-O2,CHECK-O23SZ
Restore "[ThinLTO] Add additional ThinLTO pipeline testing with new PM" This restores 2af97be8027a0823b88d4b6a07fc5eedb440bc1f (reverted at 6288f86e870c7bb7fe47cc138320b9eb34c93941), with all the fixes I had applied at the time, along with a new fix for non-determinism in the ordering of a couple of passes due to being accessed as parameters on the same call. I've also added --dump-input=fail to the new tests so I can more thoroughly fix any additional failures.
2020-01-14 03:09:13 +08:00
; RUN: opt -disable-verify -debug-pass-manager \
; RUN: -pgo-kind=pgo-sample-use-pipeline -profile-file='%S/Inputs/new-pm-thinlto-samplepgo-defaults.prof' \
[NPM] Move more O0 pass building into PassBuilder This moves handling of alwaysinline, coroutines, matrix lowering, PGO, and LTO-required passes into PassBuilder. Much of this is replicated between Clang and opt. Other out-of-tree users also replicate some of this, such as Rust [1] replicating the alwaysinline, LTO, and PGO passes. The LTO passes are also now run in build(Thin)LTOPreLinkDefaultPipeline() since they are semantically required for (Thin)LTO. [1]: https://github.com/rust-lang/rust/blob/f5230fbf76bafd86ee4376a0e26e551df8d17fec/compiler/rustc_llvm/llvm-wrapper/PassWrapper.cpp#L896 Reviewed By: tejohnson Differential Revision: https://reviews.llvm.org/D91585
2020-11-17 04:48:42 +08:00
; RUN: -passes='thinlto-pre-link<O3>' -S -passes-ep-pipeline-start='no-op-module' %s 2>&1 \
[test] Fix unused check prefixes in test/Linker/ and test/Other/
2020-10-30 12:54:45 +08:00
; RUN: | FileCheck %s --check-prefixes=CHECK-O,CHECK-O3,CHECK-O23SZ,CHECK-EP-PIPELINE-START
Restore "[ThinLTO] Add additional ThinLTO pipeline testing with new PM" This restores 2af97be8027a0823b88d4b6a07fc5eedb440bc1f (reverted at 6288f86e870c7bb7fe47cc138320b9eb34c93941), with all the fixes I had applied at the time, along with a new fix for non-determinism in the ordering of a couple of passes due to being accessed as parameters on the same call. I've also added --dump-input=fail to the new tests so I can more thoroughly fix any additional failures.
2020-01-14 03:09:13 +08:00
; RUN: opt -disable-verify -debug-pass-manager \
; RUN: -pgo-kind=pgo-sample-use-pipeline -profile-file='%S/Inputs/new-pm-thinlto-samplepgo-defaults.prof' \
[NPM] Move more O0 pass building into PassBuilder This moves handling of alwaysinline, coroutines, matrix lowering, PGO, and LTO-required passes into PassBuilder. Much of this is replicated between Clang and opt. Other out-of-tree users also replicate some of this, such as Rust [1] replicating the alwaysinline, LTO, and PGO passes. The LTO passes are also now run in build(Thin)LTOPreLinkDefaultPipeline() since they are semantically required for (Thin)LTO. [1]: https://github.com/rust-lang/rust/blob/f5230fbf76bafd86ee4376a0e26e551df8d17fec/compiler/rustc_llvm/llvm-wrapper/PassWrapper.cpp#L896 Reviewed By: tejohnson Differential Revision: https://reviews.llvm.org/D91585
2020-11-17 04:48:42 +08:00
; RUN: -passes='thinlto-pre-link<Os>' -S %s 2>&1 \
[test] Fix unused check prefixes in test/Linker/ and test/Other/
2020-10-30 12:54:45 +08:00
; RUN: | FileCheck %s --check-prefixes=CHECK-O,CHECK-Os,CHECK-O23SZ
Restore "[ThinLTO] Add additional ThinLTO pipeline testing with new PM" This restores 2af97be8027a0823b88d4b6a07fc5eedb440bc1f (reverted at 6288f86e870c7bb7fe47cc138320b9eb34c93941), with all the fixes I had applied at the time, along with a new fix for non-determinism in the ordering of a couple of passes due to being accessed as parameters on the same call. I've also added --dump-input=fail to the new tests so I can more thoroughly fix any additional failures.
2020-01-14 03:09:13 +08:00
; RUN: opt -disable-verify -debug-pass-manager \
; RUN: -pgo-kind=pgo-sample-use-pipeline -profile-file='%S/Inputs/new-pm-thinlto-samplepgo-defaults.prof' \
[NPM] Move more O0 pass building into PassBuilder This moves handling of alwaysinline, coroutines, matrix lowering, PGO, and LTO-required passes into PassBuilder. Much of this is replicated between Clang and opt. Other out-of-tree users also replicate some of this, such as Rust [1] replicating the alwaysinline, LTO, and PGO passes. The LTO passes are also now run in build(Thin)LTOPreLinkDefaultPipeline() since they are semantically required for (Thin)LTO. [1]: https://github.com/rust-lang/rust/blob/f5230fbf76bafd86ee4376a0e26e551df8d17fec/compiler/rustc_llvm/llvm-wrapper/PassWrapper.cpp#L896 Reviewed By: tejohnson Differential Revision: https://reviews.llvm.org/D91585
2020-11-17 04:48:42 +08:00
; RUN: -passes='thinlto-pre-link<Oz>' -S %s 2>&1 \
[test] Fix unused check prefixes in test/Linker/ and test/Other/
2020-10-30 12:54:45 +08:00
; RUN: | FileCheck %s --check-prefixes=CHECK-O,CHECK-Oz,CHECK-O23SZ
Restore "[ThinLTO] Add additional ThinLTO pipeline testing with new PM" This restores 2af97be8027a0823b88d4b6a07fc5eedb440bc1f (reverted at 6288f86e870c7bb7fe47cc138320b9eb34c93941), with all the fixes I had applied at the time, along with a new fix for non-determinism in the ordering of a couple of passes due to being accessed as parameters on the same call. I've also added --dump-input=fail to the new tests so I can more thoroughly fix any additional failures.
2020-01-14 03:09:13 +08:00
; RUN: opt -disable-verify -debug-pass-manager -new-pm-debug-info-for-profiling \
; RUN: -pgo-kind=pgo-sample-use-pipeline -profile-file='%S/Inputs/new-pm-thinlto-samplepgo-defaults.prof' \
[NPM] Move more O0 pass building into PassBuilder This moves handling of alwaysinline, coroutines, matrix lowering, PGO, and LTO-required passes into PassBuilder. Much of this is replicated between Clang and opt. Other out-of-tree users also replicate some of this, such as Rust [1] replicating the alwaysinline, LTO, and PGO passes. The LTO passes are also now run in build(Thin)LTOPreLinkDefaultPipeline() since they are semantically required for (Thin)LTO. [1]: https://github.com/rust-lang/rust/blob/f5230fbf76bafd86ee4376a0e26e551df8d17fec/compiler/rustc_llvm/llvm-wrapper/PassWrapper.cpp#L896 Reviewed By: tejohnson Differential Revision: https://reviews.llvm.org/D91585
2020-11-17 04:48:42 +08:00
; RUN: -passes='thinlto-pre-link<O2>' -S %s 2>&1 \
[test] Fix unused check prefixes in test/Linker/ and test/Other/
2020-10-30 12:54:45 +08:00
; RUN: | FileCheck %s --check-prefixes=CHECK-O,CHECK-O2,CHECK-O23SZ
Restore "[ThinLTO] Add additional ThinLTO pipeline testing with new PM" This restores 2af97be8027a0823b88d4b6a07fc5eedb440bc1f (reverted at 6288f86e870c7bb7fe47cc138320b9eb34c93941), with all the fixes I had applied at the time, along with a new fix for non-determinism in the ordering of a couple of passes due to being accessed as parameters on the same call. I've also added --dump-input=fail to the new tests so I can more thoroughly fix any additional failures.
2020-01-14 03:09:13 +08:00
;
[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: Starting {{.*}}Module pass manager run.
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 17:49:04 +08:00
; CHECK-O-NEXT: Running pass: Annotation2Metadata
Restore "[ThinLTO] Add additional ThinLTO pipeline testing with new PM" This restores 2af97be8027a0823b88d4b6a07fc5eedb440bc1f (reverted at 6288f86e870c7bb7fe47cc138320b9eb34c93941), with all the fixes I had applied at the time, along with a new fix for non-determinism in the ordering of a couple of passes due to being accessed as parameters on the same call. I've also added --dump-input=fail to the new tests so I can more thoroughly fix any additional failures.
2020-01-14 03:09:13 +08:00
; CHECK-O-NEXT: Running pass: ForceFunctionAttrsPass
; CHECK-O-NEXT: Running analysis: InnerAnalysisManagerProxy
[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: AddDiscriminatorsPass
Restore "[ThinLTO] Add additional ThinLTO pipeline testing with new PM" This restores 2af97be8027a0823b88d4b6a07fc5eedb440bc1f (reverted at 6288f86e870c7bb7fe47cc138320b9eb34c93941), with all the fixes I had applied at the time, along with a new fix for non-determinism in the ordering of a couple of passes due to being accessed as parameters on the same call. I've also added --dump-input=fail to the new tests so I can more thoroughly fix any additional failures.
2020-01-14 03:09:13 +08:00
; CHECK-EP-PIPELINE-START-NEXT: Running pass: NoOpModulePass
; CHECK-O-NEXT: Running pass: InferFunctionAttrsPass
; CHECK-O-NEXT: Running analysis: TargetLibraryAnalysis
; CHECK-O-NEXT: Starting {{.*}}Function pass manager run.
; CHECK-O-NEXT: Running pass: SimplifyCFGPass
; CHECK-O-NEXT: Running analysis: TargetIRAnalysis
; CHECK-O-NEXT: Running analysis: AssumptionAnalysis
; CHECK-O-NEXT: Running pass: SROA
; CHECK-O-NEXT: Running analysis: DominatorTreeAnalysis
; CHECK-O-NEXT: Running pass: EarlyCSEPass
; CHECK-O-NEXT: Running analysis: TargetLibraryAnalysis
; CHECK-O-NEXT: Running pass: LowerExpectIntrinsicPass
; CHECK-O3-NEXT: Running pass: CallSiteSplittingPass
; CHECK-O-NEXT: Running pass: InstCombinePass on foo
; CHECK-O-NEXT: Running analysis: OptimizationRemarkEmitterAnalysis on foo
; CHECK-O-NEXT: Running analysis: AAManager on foo
[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-O-NEXT: Running analysis: ScopedNoAliasAA
; CHECK-O-NEXT: Running analysis: TypeBasedAA
Restore "[ThinLTO] Add additional ThinLTO pipeline testing with new PM" This restores 2af97be8027a0823b88d4b6a07fc5eedb440bc1f (reverted at 6288f86e870c7bb7fe47cc138320b9eb34c93941), with all the fixes I had applied at the time, along with a new fix for non-determinism in the ordering of a couple of passes due to being accessed as parameters on the same call. I've also added --dump-input=fail to the new tests so I can more thoroughly fix any additional failures.
2020-01-14 03:09:13 +08:00
; CHECK-O-NEXT: Running analysis: OuterAnalysisManagerProxy
; CHECK-O-NEXT: Finished {{.*}}Function pass manager run.
; CHECK-O-NEXT: Running pass: SampleProfileLoaderPass
; CHECK-O-NEXT: Running analysis: ProfileSummaryAnalysis
; CHECK-O-NEXT: Running analysis: CallGraphAnalysis
; CHECK-O-NEXT: Running pass: RequireAnalysisPass<{{.*}}ProfileSummaryAnalysis
; CHECK-O-NEXT: Running pass: IPSCCPPass
; CHECK-O-NEXT: Running pass: CalledValuePropagationPass
; CHECK-O-NEXT: Running pass: GlobalOptPass
[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: PromotePass
Restore "[ThinLTO] Add additional ThinLTO pipeline testing with new PM" This restores 2af97be8027a0823b88d4b6a07fc5eedb440bc1f (reverted at 6288f86e870c7bb7fe47cc138320b9eb34c93941), with all the fixes I had applied at the time, along with a new fix for non-determinism in the ordering of a couple of passes due to being accessed as parameters on the same call. I've also added --dump-input=fail to the new tests so I can more thoroughly fix any additional failures.
2020-01-14 03:09:13 +08:00
; CHECK-O-NEXT: Running pass: DeadArgumentEliminationPass
; CHECK-O-NEXT: Starting {{.*}}Function pass manager run.
; CHECK-O-NEXT: Running pass: InstCombinePass
; CHECK-O-NEXT: Running analysis: BlockFrequencyAnalysis on foo
; These next two can appear in any order since they are accessed as parameters
; on the same call to BlockFrequencyInfo::calculate.
; CHECK-O-DAG: Running analysis: LoopAnalysis on foo
[BPI][NFC] Reuse post dominantor tree from analysis manager when available Summary: Currenlty BPI unconditionally creates post dominator tree each time. While this is not incorrect we can save compile time by reusing existing post dominator tree (when it's valid) provided by analysis manager. Reviewers: skatkov, taewookoh, yrouban Reviewed By: skatkov Subscribers: hiraditya, steven_wu, dexonsmith, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D78987
2020-04-28 17:31:20 +08:00
; CHECK-O-DAG: Running analysis: BranchProbabilityAnalysis on foo
; CHECK-O-NEXT: Running analysis: PostDominatorTreeAnalysis on foo
Restore "[ThinLTO] Add additional ThinLTO pipeline testing with new PM" This restores 2af97be8027a0823b88d4b6a07fc5eedb440bc1f (reverted at 6288f86e870c7bb7fe47cc138320b9eb34c93941), with all the fixes I had applied at the time, along with a new fix for non-determinism in the ordering of a couple of passes due to being accessed as parameters on the same call. I've also added --dump-input=fail to the new tests so I can more thoroughly fix any additional failures.
2020-01-14 03:09:13 +08:00
; CHECK-O-NEXT: Running pass: SimplifyCFGPass on foo
; CHECK-O-NEXT: Finished {{.*}}Function pass manager run
[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-29 04:25:15 +08:00
; CHECK-O-NEXT: Running pass: ModuleInlinerWrapperPass
; CHECK-O-NEXT: Running analysis: InlineAdvisorAnalysis
[PassBuilder] Moved ProfileSummaryAnalysis in buildInlinerPipeline. Summary: As commented in the code, ProfileSummaryAnalysis is required for inliner pass to query, so this patch moved RequireAnalysisPass<ProfileSummaryAnalysis> in the recently created buildInlinerPipeline. Reviewer: mtrofin, davidxl, tejohnson, dblaikie, jdoerfert, sstefan1 Reviewed By: mtrofin, davidxl, jdoerfert Subscribers: hiraditya, steven_wu, dexonsmith, wuzish, llvm-commits, jsji Tag: LLVM Differential Revision: https://reviews.llvm.org/D79696
2020-05-12 23:56:14 +08:00
; CHECK-O-NEXT: Starting {{.*}}Module pass manager run.
[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-16 05:56:57 +08:00
; CHECK-O-NEXT: Running pass: RequireAnalysisPass<{{.*}}GlobalsAA
; CHECK-O-NEXT: Running analysis: GlobalsAA
; CHECK-O-NEXT: Running pass: RequireAnalysisPass<{{.*}}ProfileSummaryAnalysis
Restore "[ThinLTO] Add additional ThinLTO pipeline testing with new PM" This restores 2af97be8027a0823b88d4b6a07fc5eedb440bc1f (reverted at 6288f86e870c7bb7fe47cc138320b9eb34c93941), with all the fixes I had applied at the time, along with a new fix for non-determinism in the ordering of a couple of passes due to being accessed as parameters on the same call. I've also added --dump-input=fail to the new tests so I can more thoroughly fix any additional failures.
2020-01-14 03:09:13 +08:00
; CHECK-O-NEXT: Running analysis: InnerAnalysisManagerProxy
; CHECK-O-NEXT: Running analysis: LazyCallGraphAnalysis
; CHECK-O-NEXT: Running analysis: FunctionAnalysisManagerCGSCCProxy
; CHECK-O-NEXT: Running analysis: OuterAnalysisManagerProxy<{{.*}}LazyCallGraph::SCC{{.*}}>
[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: DevirtSCCRepeatedPass
Restore "[ThinLTO] Add additional ThinLTO pipeline testing with new PM" This restores 2af97be8027a0823b88d4b6a07fc5eedb440bc1f (reverted at 6288f86e870c7bb7fe47cc138320b9eb34c93941), with all the fixes I had applied at the time, along with a new fix for non-determinism in the ordering of a couple of passes due to being accessed as parameters on the same call. I've also added --dump-input=fail to the new tests so I can more thoroughly fix any additional failures.
2020-01-14 03:09:13 +08:00
; CHECK-O-NEXT: Starting CGSCC pass manager run.
; CHECK-O-NEXT: Running pass: InlinerPass
[llvm][inliner] Reuse the inliner pass to implement 'always inliner' Enable performing mandatory inlinings upfront, by reusing the same logic as the full inliner, instead of the AlwaysInliner. This has the following benefits: - reduce code duplication - one inliner codebase - open the opportunity to help the full inliner by performing additional function passes after the mandatory inlinings, but before th full inliner. Performing the mandatory inlinings first simplifies the problem the full inliner needs to solve: less call sites, more contextualization, and, depending on the additional function optimization passes run between the 2 inliners, higher accuracy of cost models / decision policies. Note that this patch does not yet enable much in terms of post-always inline function optimization. Differential Revision: https://reviews.llvm.org/D91567
2020-11-17 06:01:53 +08:00
; CHECK-O-NEXT: Running pass: InlinerPass
Restore "[ThinLTO] Add additional ThinLTO pipeline testing with new PM" This restores 2af97be8027a0823b88d4b6a07fc5eedb440bc1f (reverted at 6288f86e870c7bb7fe47cc138320b9eb34c93941), with all the fixes I had applied at the time, along with a new fix for non-determinism in the ordering of a couple of passes due to being accessed as parameters on the same call. I've also added --dump-input=fail to the new tests so I can more thoroughly fix any additional failures.
2020-01-14 03:09:13 +08:00
; CHECK-O-NEXT: Running pass: PostOrderFunctionAttrsPass
; CHECK-O3-NEXT: Running pass: ArgumentPromotionPass
[FIX] Update PM tests after D69930 landed
2020-02-09 05:22:03 +08:00
; CHECK-O2-NEXT: Running pass: OpenMPOptPass
; CHECK-O3-NEXT: Running pass: OpenMPOptPass
Restore "[ThinLTO] Add additional ThinLTO pipeline testing with new PM" This restores 2af97be8027a0823b88d4b6a07fc5eedb440bc1f (reverted at 6288f86e870c7bb7fe47cc138320b9eb34c93941), with all the fixes I had applied at the time, along with a new fix for non-determinism in the ordering of a couple of passes due to being accessed as parameters on the same call. I've also added --dump-input=fail to the new tests so I can more thoroughly fix any additional failures.
2020-01-14 03:09:13 +08:00
; CHECK-O-NEXT: Starting {{.*}}Function pass manager run.
; CHECK-O-NEXT: Running pass: SROA
; CHECK-O-NEXT: Running pass: EarlyCSEPass
; CHECK-O-NEXT: Running analysis: MemorySSAAnalysis
; CHECK-O23SZ-NEXT: Running pass: SpeculativeExecutionPass
; CHECK-O23SZ-NEXT: Running pass: JumpThreadingPass
; CHECK-O23SZ-NEXT: Running analysis: LazyValueAnalysis
; CHECK-O23SZ-NEXT: Running pass: CorrelatedValuePropagationPass
[NewPM][LVI] Abandon LVI after CVP As mentioned on D70376, LVI can currently cause performance issues when running under NewPM. The problem is that, unlike the legacy pass manager, NewPM will not immediately discard the LVI analysis if the following pass does not need it. This is a problem, because LVI has a high memory requirement, and mass invalidation of LVI values is very inefficient. LVI should only be alive during passes that actively interact with it. This patch addresses the issue by explicitly abandoning LVI after CVP, which gets us back to the LegacyPM behavior. Differential Revision: https://reviews.llvm.org/D84959
2020-07-31 01:14:02 +08:00
; CHECK-O23SZ-NEXT: Invalidating analysis: LazyValueAnalysis
Restore "[ThinLTO] Add additional ThinLTO pipeline testing with new PM" This restores 2af97be8027a0823b88d4b6a07fc5eedb440bc1f (reverted at 6288f86e870c7bb7fe47cc138320b9eb34c93941), with all the fixes I had applied at the time, along with a new fix for non-determinism in the ordering of a couple of passes due to being accessed as parameters on the same call. I've also added --dump-input=fail to the new tests so I can more thoroughly fix any additional failures.
2020-01-14 03:09:13 +08:00
; CHECK-O-NEXT: Running pass: SimplifyCFGPass
; CHECK-O3-NEXT: Running pass: AggressiveInstCombinePass
; CHECK-O-NEXT: Running pass: InstCombinePass
; CHECK-O1-NEXT: Running pass: LibCallsShrinkWrapPass
; CHECK-O2-NEXT: Running pass: LibCallsShrinkWrapPass
; CHECK-O3-NEXT: Running pass: LibCallsShrinkWrapPass
; CHECK-O23SZ-NEXT: Running pass: TailCallElimPass
; CHECK-O-NEXT: Running pass: SimplifyCFGPass
; CHECK-O-NEXT: Running pass: ReassociatePass
; CHECK-O-NEXT: Running pass: RequireAnalysisPass<{{.*}}OptimizationRemarkEmitterAnalysis
; CHECK-O-NEXT: Starting {{.*}}Function pass manager run
; CHECK-O-NEXT: Running pass: LoopSimplifyPass
; CHECK-O-NEXT: Running pass: LCSSAPass
; CHECK-O-NEXT: Finished {{.*}}Function pass manager run
; CHECK-O-NEXT: Running analysis: ScalarEvolutionAnalysis
; CHECK-O-NEXT: Running analysis: InnerAnalysisManagerProxy
; CHECK-O-NEXT: Starting Loop pass manager run.
; CHECK-O-NEXT: Running pass: LoopInstSimplifyPass
; CHECK-O-NEXT: Running pass: LoopSimplifyCFGPass
; CHECK-O-NEXT: Running pass: LoopRotatePass
; CHECK-O-NEXT: Running pass: LICM
; CHECK-O-NEXT: Running pass: SimpleLoopUnswitchPass
; CHECK-O-NEXT: Finished Loop pass manager run.
; CHECK-O-NEXT: Running pass: SimplifyCFGPass
; CHECK-O-NEXT: Running pass: InstCombinePass
; CHECK-O-NEXT: Starting {{.*}}Function pass manager run
; CHECK-O-NEXT: Running pass: LoopSimplifyPass
; CHECK-O-NEXT: Running pass: LCSSAPass
; CHECK-O-NEXT: Finished {{.*}}Function pass manager run
; CHECK-O-NEXT: Starting Loop pass manager run.
; CHECK-O-NEXT: Running pass: LoopIdiomRecognizePass
[PassManager] Run Induction Variable Simplification pass *after* Recognize loop idioms pass, not before Currently, `-indvars` runs first, and then immediately after `-loop-idiom` does. I'm not really sure if `-loop-idiom` requires `-indvars` to run beforehand, but i'm *very* sure that `-indvars` requires `-loop-idiom` to run afterwards, as it can be seen in the phase-ordering test. LoopIdiom runs on two types of loops: countable ones, and uncountable ones. For uncountable ones, IndVars obviously didn't make any change to them, since they are uncountable, so for them the order should be irrelevant. For countable ones, well, they should have been countable before IndVars for IndVars to make any change to them, and since SCEV is used on them, it shouldn't matter if IndVars have already canonicalized them. So i don't really see why we'd want the current ordering. Should this cause issues, it will give us a reproducer test case that shows flaws in this logic, and we then could adjust accordingly. While this is quite likely beneficial in-the-wild already, it's a required part for the full motivational pattern behind `left-shift-until-bittest` loop idiom (D91038). Reviewed By: dmgreen Differential Revision: https://reviews.llvm.org/D91800
2020-11-26 00:17:25 +08:00
; CHECK-O-NEXT: Running pass: IndVarSimplifyPass
Restore "[ThinLTO] Add additional ThinLTO pipeline testing with new PM" This restores 2af97be8027a0823b88d4b6a07fc5eedb440bc1f (reverted at 6288f86e870c7bb7fe47cc138320b9eb34c93941), with all the fixes I had applied at the time, along with a new fix for non-determinism in the ordering of a couple of passes due to being accessed as parameters on the same call. I've also added --dump-input=fail to the new tests so I can more thoroughly fix any additional failures.
2020-01-14 03:09:13 +08:00
; CHECK-O-NEXT: Running pass: LoopDeletionPass
; CHECK-O-NEXT: Finished Loop pass manager run.
; CHECK-O-NEXT: Running pass: SROA on foo
; CHECK-Os-NEXT: Running pass: MergedLoadStoreMotionPass
; CHECK-Os-NEXT: Running pass: GVN
; CHECK-Os-NEXT: Running analysis: MemoryDependenceAnalysis
; CHECK-Os-NEXT: Running analysis: PhiValuesAnalysis
; CHECK-Oz-NEXT: Running pass: MergedLoadStoreMotionPass
; CHECK-Oz-NEXT: Running pass: GVN
; CHECK-Oz-NEXT: Running analysis: MemoryDependenceAnalysis
; CHECK-Oz-NEXT: Running analysis: PhiValuesAnalysis
; CHECK-O2-NEXT: Running pass: MergedLoadStoreMotionPass
; CHECK-O2-NEXT: Running pass: GVN
; CHECK-O2-NEXT: Running analysis: MemoryDependenceAnalysis
; CHECK-O2-NEXT: Running analysis: PhiValuesAnalysis
; CHECK-O3-NEXT: Running pass: MergedLoadStoreMotionPass
; CHECK-O3-NEXT: Running pass: GVN
; CHECK-O3-NEXT: Running analysis: MemoryDependenceAnalysis
; CHECK-O3-NEXT: Running analysis: PhiValuesAnalysis
; CHECK-O-NEXT: Running pass: MemCpyOptPass
; CHECK-O1-NEXT: Running analysis: MemoryDependenceAnalysis
; CHECK-O1-NEXT: Running analysis: PhiValuesAnalysis
; CHECK-O-NEXT: Running pass: SCCPPass
; CHECK-O-NEXT: Running pass: BDCEPass
; CHECK-O-NEXT: Running analysis: DemandedBitsAnalysis
; CHECK-O-NEXT: Running pass: InstCombinePass
; CHECK-O23SZ-NEXT: Running pass: JumpThreadingPass
[NewPM][LVI] Abandon LVI after CVP As mentioned on D70376, LVI can currently cause performance issues when running under NewPM. The problem is that, unlike the legacy pass manager, NewPM will not immediately discard the LVI analysis if the following pass does not need it. This is a problem, because LVI has a high memory requirement, and mass invalidation of LVI values is very inefficient. LVI should only be alive during passes that actively interact with it. This patch addresses the issue by explicitly abandoning LVI after CVP, which gets us back to the LegacyPM behavior. Differential Revision: https://reviews.llvm.org/D84959
2020-07-31 01:14:02 +08:00
; CHECK-O23SZ-NEXT: Running analysis: LazyValueAnalysis
Restore "[ThinLTO] Add additional ThinLTO pipeline testing with new PM" This restores 2af97be8027a0823b88d4b6a07fc5eedb440bc1f (reverted at 6288f86e870c7bb7fe47cc138320b9eb34c93941), with all the fixes I had applied at the time, along with a new fix for non-determinism in the ordering of a couple of passes due to being accessed as parameters on the same call. I've also added --dump-input=fail to the new tests so I can more thoroughly fix any additional failures.
2020-01-14 03:09:13 +08:00
; CHECK-O23SZ-NEXT: Running pass: CorrelatedValuePropagationPass
[NewPM][LVI] Abandon LVI after CVP As mentioned on D70376, LVI can currently cause performance issues when running under NewPM. The problem is that, unlike the legacy pass manager, NewPM will not immediately discard the LVI analysis if the following pass does not need it. This is a problem, because LVI has a high memory requirement, and mass invalidation of LVI values is very inefficient. LVI should only be alive during passes that actively interact with it. This patch addresses the issue by explicitly abandoning LVI after CVP, which gets us back to the LegacyPM behavior. Differential Revision: https://reviews.llvm.org/D84959
2020-07-31 01:14:02 +08:00
; CHECK-O23SZ-NEXT: Invalidating analysis: LazyValueAnalysis
[Passes] Move ADCE before DSE & LICM. The adjustment seems to have very little impact on optimizations. The only binary change with -O3 MultiSource/SPEC2000/SPEC2006 on X86 is in consumer-typeset and the size there actually decreases by -0.1%, with not significant changes in the stats. On its own, it is mildly positive in terms of compile-time, most likely due to LICM & DSE having to process slightly less instructions. It should also be unlikely that DSE/LICM make much new code dead. http://llvm-compile-time-tracker.com/compare.php?from=df63eedef64d715ce1f31843f7de9c11fe1e597f&to=e3bdfcf94a9eeae6e006d010464f0c1b3550577d&stat=instructions With DSE & MemorySSA, it gives some nice compile-time improvements, due to the fact that DSE can re-use the PDT from ADCE, if it does not make any changes: http://llvm-compile-time-tracker.com/compare.php?from=15fdd6cd7c24c745df1bb419e72ff66fd138aa7e&to=481f494515fc89cb7caea8d862e40f2c910dc994&stat=instructions Reviewed By: xbolva00 Differential Revision: https://reviews.llvm.org/D87322
2020-10-21 17:21:50 +08:00
; CHECK-O-NEXT: Running pass: ADCEPass
Restore "[ThinLTO] Add additional ThinLTO pipeline testing with new PM" This restores 2af97be8027a0823b88d4b6a07fc5eedb440bc1f (reverted at 6288f86e870c7bb7fe47cc138320b9eb34c93941), with all the fixes I had applied at the time, along with a new fix for non-determinism in the ordering of a couple of passes due to being accessed as parameters on the same call. I've also added --dump-input=fail to the new tests so I can more thoroughly fix any additional failures.
2020-01-14 03:09:13 +08:00
; CHECK-O23SZ-NEXT: Running pass: DSEPass
; CHECK-O23SZ-NEXT: Starting {{.*}}Function pass manager run
; CHECK-O23SZ-NEXT: Running pass: LoopSimplifyPass
; CHECK-O23SZ-NEXT: Running pass: LCSSAPass
; CHECK-O23SZ-NEXT: Finished {{.*}}Function pass manager run
[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-O23SZ-NEXT: Running pass: LICMPass
Restore "[ThinLTO] Add additional ThinLTO pipeline testing with new PM" This restores 2af97be8027a0823b88d4b6a07fc5eedb440bc1f (reverted at 6288f86e870c7bb7fe47cc138320b9eb34c93941), with all the fixes I had applied at the time, along with a new fix for non-determinism in the ordering of a couple of passes due to being accessed as parameters on the same call. I've also added --dump-input=fail to the new tests so I can more thoroughly fix any additional failures.
2020-01-14 03:09:13 +08:00
; CHECK-O-NEXT: Running pass: SimplifyCFGPass
; CHECK-O-NEXT: Running pass: InstCombinePass
; CHECK-O3-NEXT: Running pass: ControlHeightReductionPass on foo
; CHECK-O3-NEXT: Running analysis: RegionInfoAnalysis on foo
; CHECK-O3-NEXT: Running analysis: DominanceFrontierAnalysis on foo
; CHECK-O-NEXT: Finished {{.*}}Function pass manager run.
; CHECK-O-NEXT: Finished CGSCC pass manager run.
; CHECK-O-NEXT: Finished {{.*}}Module pass manager run.
; CHECK-O-NEXT: Running pass: GlobalOptPass
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
[NPM] Move more O0 pass building into PassBuilder This moves handling of alwaysinline, coroutines, matrix lowering, PGO, and LTO-required passes into PassBuilder. Much of this is replicated between Clang and opt. Other out-of-tree users also replicate some of this, such as Rust [1] replicating the alwaysinline, LTO, and PGO passes. The LTO passes are also now run in build(Thin)LTOPreLinkDefaultPipeline() since they are semantically required for (Thin)LTO. [1]: https://github.com/rust-lang/rust/blob/f5230fbf76bafd86ee4376a0e26e551df8d17fec/compiler/rustc_llvm/llvm-wrapper/PassWrapper.cpp#L896 Reviewed By: tejohnson Differential Revision: https://reviews.llvm.org/D91585
2020-11-17 04:48:42 +08:00
; CHECK-O-NEXT: Running pass: CanonicalizeAliasesPass
Restore "[ThinLTO] Add additional ThinLTO pipeline testing with new PM" This restores 2af97be8027a0823b88d4b6a07fc5eedb440bc1f (reverted at 6288f86e870c7bb7fe47cc138320b9eb34c93941), with all the fixes I had applied at the time, along with a new fix for non-determinism in the ordering of a couple of passes due to being accessed as parameters on the same call. I've also added --dump-input=fail to the new tests so I can more thoroughly fix any additional failures.
2020-01-14 03:09:13 +08:00
; CHECK-O-NEXT: Running pass: NameAnonGlobalPass
; 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: }
;
; Ignore a bunch of intervening metadata containing profile data.
;
; CHECK-O: Finished {{.*}}Module pass manager run.
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
}