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-postlink-pgo...

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

273 lines
13 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 post link pipeline when we have instrumentation PGO
;
; Postlink pipelines:
; RUN: opt -disable-verify -debug-pass-manager \
; RUN: -passes='thinlto<O1>' -S %s 2>&1 \
; RUN: | FileCheck %s --check-prefixes=CHECK-O,CHECK-O1,%llvmcheckext --dump-input=fail
; RUN: opt -disable-verify -debug-pass-manager \
; RUN: -passes='thinlto<O2>' -S %s 2>&1 \
; RUN: | FileCheck %s --check-prefixes=CHECK-O,CHECK-O2,CHECK-O23SZ,%llvmcheckext --dump-input=fail
; RUN: opt -disable-verify -debug-pass-manager -passes-ep-pipeline-start='no-op-module' \
; RUN: -passes='thinlto<O3>' -S %s 2>&1 \
; RUN: | FileCheck %s --check-prefixes=CHECK-O,CHECK-O3,CHECK-O23SZ,%llvmcheckext --dump-input=fail
; RUN: opt -disable-verify -debug-pass-manager \
; RUN: -passes='thinlto<Os>' -S %s 2>&1 \
; RUN: | FileCheck %s --check-prefixes=CHECK-O,CHECK-Os,CHECK-O23SZ,%llvmcheckext --dump-input=fail
; RUN: opt -disable-verify -debug-pass-manager \
; RUN: -passes='thinlto<Oz>' -S %s 2>&1 \
; RUN: | FileCheck %s --check-prefixes=CHECK-O,CHECK-Oz,CHECK-O23SZ,%llvmcheckext --dump-input=fail
; RUN: opt -disable-verify -debug-pass-manager -new-pm-debug-info-for-profiling \
; RUN: -passes='thinlto<O2>' -S %s 2>&1 \
; RUN: | FileCheck %s --check-prefixes=CHECK-O,CHECK-O2,CHECK-O23SZ,%llvmcheckext --dump-input=fail
;
[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.
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-EP-PIPELINE-START-NEXT: Running pass: NoOpModulePass
; CHECK-O-NEXT: Running pass: PGOIndirectCallPromotion
; CHECK-O-NEXT: Running analysis: ProfileSummaryAnalysis
; CHECK-O-NEXT: Running analysis: InnerAnalysisManagerProxy
; CHECK-O-NEXT: Running analysis: OptimizationRemarkEmitterAnalysis
; 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: Finished {{.*}}Function pass manager run.
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
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: 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: AAManager
; CHECK-O-NEXT: Running analysis: OuterAnalysisManagerProxy
; 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
; 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.
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: RequireAnalysisPass<{{.*}}GlobalsAA
; CHECK-O-NEXT: Running analysis: GlobalsAA
; CHECK-O-NEXT: Running analysis: CallGraphAnalysis
; CHECK-O-NEXT: Running pass: RequireAnalysisPass<{{.*}}ProfileSummaryAnalysis
[Inliner] Run always-inliner in inliner-wrapper An alwaysinline function may not get inlined in inliner-wrapper due to the inlining order. Previously for the following, the inliner would first inline @a() into @b(), ``` define void @a() { entry: call void @b() ret void } define void @b() alwaysinline { entry: br label %for.cond for.cond: call void @a() br label %for.cond } ``` making @b() recursive and unable to be inlined into @a(), ending at ``` define void @a() { entry: call void @b() ret void } define void @b() alwaysinline { entry: br label %for.cond for.cond: call void @b() br label %for.cond } ``` Running always-inliner first makes sure that we respect alwaysinline in more cases. Fixes https://bugs.llvm.org/show_bug.cgi?id=46945. Reviewed By: davidxl, rnk Differential Revision: https://reviews.llvm.org/D86988
2020-09-02 06:55:05 +08:00
; CHECK-O-NEXT: Running pass: AlwaysInlinerPass
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
; 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: IndVarSimplifyPass
; CHECK-O-NEXT: Running pass: LoopIdiomRecognizePass
; CHECK-O-NEXT: Running pass: LoopDeletionPass
; CHECK-O-NEXT: Running pass: LoopFullUnrollPass
; 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-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
; CHECK-O-NEXT: Running pass: GlobalDCEPass
; CHECK-O-NEXT: Running pass: EliminateAvailableExternallyPass
; CHECK-O-NEXT: Running pass: ReversePostOrderFunctionAttrsPass
; CHECK-O-NEXT: Running pass: RequireAnalysisPass<{{.*}}GlobalsAA
; CHECK-O-NEXT: Starting {{.*}}Function pass manager run.
; CHECK-O-NEXT: Running pass: Float2IntPass
; CHECK-O-NEXT: Running pass: LowerConstantIntrinsicsPass
; CHECK-EXT: Running pass: {{.*}}::Bye
[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: Starting {{.*}}Function pass manager run.
; CHECK-O-NEXT: Running pass: LoopSimplifyPass on foo
; CHECK-O-NEXT: Running pass: LCSSAPass on foo
; CHECK-O-NEXT: Finished {{.*}}Function pass manager run.
; CHECK-O-NEXT: Running pass: LoopRotatePass
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: LoopDistributePass
Add InjectTLIMappings pass to new pass manager This pass is created in d6de5f12d485a85504bc99d384a85634574a27e2 and tested for new and legacy pass manager but never added to new pass manager pipeline. I am adding it to new pass manager pipeline. This pass is get used in Vector Function Database (VFDatabase) and without this pass in new pass manager pipeline, none of the vector libraries are work ing with new pass manager. Related passes: 66c120f02560ef528a60924104ead66f330190f1 https://reviews.llvm.org/D74944 Differential revision: https://reviews.llvm.org/D75354
2020-04-07 02:16:48 +08:00
; CHECK-O-NEXT: Running pass: InjectTLIMappings
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: LoopVectorizePass
; CHECK-O-NEXT: Running pass: LoopLoadEliminationPass
; CHECK-O-NEXT: Running analysis: LoopAccessAnalysis
; CHECK-O-NEXT: Running pass: InstCombinePass
; CHECK-O-NEXT: Running pass: SimplifyCFGPass
; CHECK-O2-NEXT: Running pass: SLPVectorizerPass
; CHECK-O3-NEXT: Running pass: SLPVectorizerPass
; CHECK-Os-NEXT: Running pass: SLPVectorizerPass
[VectorCombine] position pass after SLP in the optimization pipeline rather than before There are 2 known problem patterns shown in the test diffs here: vector horizontal ops (an x86 specialization) and vector reductions. SLP has greater ability to match and fold those than vector-combine, so let SLP have first chance at that. This is a quick fix while we continue to improve vector-combine and possibly canonicalize to reduction intrinsics. In the longer term, we should improve matching of these patterns because if they were created in the "bad" forms shown here, then we would miss optimizing them. I'm not sure what is happening with alias analysis on the addsub test. The old pass manager now shows an extra line for that, and we see an improvement that comes from SLP vectorizing a store. I don't know what's missing with the new pass manager to make that happen. Strangely, I can't reproduce the behavior if I compile from C++ with clang and invoke the new PM with "-fexperimental-new-pass-manager". Differential Revision: https://reviews.llvm.org/D80236
2020-05-23 00:13:18 +08:00
; CHECK-O-NEXT: Running pass: VectorCombinePass
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: InstCombinePass
; CHECK-O-NEXT: Running pass: LoopUnrollPass
; CHECK-O-NEXT: Running pass: WarnMissedTransformationsPass
; CHECK-O-NEXT: Running pass: InstCombinePass
; 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
[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: 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: AlignmentFromAssumptionsPass
; CHECK-O-NEXT: Running pass: LoopSinkPass
; CHECK-O-NEXT: Running pass: InstSimplifyPass
; CHECK-O-NEXT: Running pass: DivRemPairsPass
; CHECK-O-NEXT: Running pass: SimplifyCFGPass
; CHECK-O-NEXT: Running pass: SpeculateAroundPHIsPass
; CHECK-O-NEXT: Finished {{.*}}Function pass manager run.
; CHECK-O-NEXT: Running pass: CGProfilePass
; CHECK-O-NEXT: Running pass: GlobalDCEPass
; CHECK-O-NEXT: Running pass: ConstantMergePass
; 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
}
!llvm.module.flags = !{!0}
!0 = !{i32 1, !"ProfileSummary", !1}
!1 = !{!2, !3, !4, !5, !6, !7, !8, !9}
!2 = !{!"ProfileFormat", !"InstrProf"}
!3 = !{!"TotalCount", i64 0}
!4 = !{!"MaxCount", i64 0}
!5 = !{!"MaxInternalCount", i64 0}
!6 = !{!"MaxFunctionCount", i64 0}
!7 = !{!"NumCounts", i64 0}
!8 = !{!"NumFunctions", i64 0}
!9 = !{!"DetailedSummary", !10}
!10 = !{!11, !12, !13, !14, !15, !16, !17, !18, !19, !20, !21, !22, !23, !24, !25, !26}
!11 = !{i32 10000, i64 0, i32 0}
!12 = !{i32 100000, i64 0, i32 0}
!13 = !{i32 200000, i64 0, i32 0}
!14 = !{i32 300000, i64 0, i32 0}
!15 = !{i32 400000, i64 0, i32 0}
!16 = !{i32 500000, i64 0, i32 0}
!17 = !{i32 600000, i64 0, i32 0}
!18 = !{i32 700000, i64 0, i32 0}
!19 = !{i32 800000, i64 0, i32 0}
!20 = !{i32 900000, i64 0, i32 0}
!21 = !{i32 950000, i64 0, i32 0}
!22 = !{i32 990000, i64 0, i32 0}
!23 = !{i32 999000, i64 0, i32 0}
!24 = !{i32 999900, i64 0, i32 0}
!25 = !{i32 999990, i64 0, i32 0}
!26 = !{i32 999999, i64 0, i32 0}