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.

280 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 \
[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,%llvmcheckext
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: -passes='thinlto<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,%llvmcheckext
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 -passes-ep-pipeline-start='no-op-module' \
; RUN: -passes='thinlto<O3>' -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-O3,CHECK-O23SZ,%llvmcheckext
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: -passes='thinlto<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,%llvmcheckext
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: -passes='thinlto<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,%llvmcheckext
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: -passes='thinlto<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,%llvmcheckext
; Suppress FileCheck --allow-unused-prefixes=false diagnostics.
; CHECK-NOEXT: {{^}}
[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-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
[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: 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.
Revert "[Passes] Add relative lookup table converter pass" This reverts commit 5178ffc7cf92527557ae16e86d0fa90d538c2a19. Compiling `llvm-profdata` with a compiler build from this produces a crashing binary.
2021-03-30 20:13:37 +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
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: 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
[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-O1-NEXT: Running pass: MemCpyOptPass
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: 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
[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: MemCpyOptPass
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
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
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: 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}