search for: loopfullunrollpass

...ront of "Loop". For readability, I would have preferred the > parallel info as a "tag", such as `Loop (parallel) as depth 1`, but > this would break other tests that check "Loop at depth 1". Later I > noticed that there are regression tests that check "LoopFullUnrollPass > on Loop at depth 3 containing: %l0.0.0<header>", but it seems I got > lucky in that none of these loops have parallel annotations. > > "CHECK-NOT" is inherently fragile. It is too easy to make a change in > LLVM that changes the text output and oversee that...

On 7/1/20 12:40 AM, Michael Kruse via llvm-dev wrote: > To illustrate some difficulties with FileCheck, lets make a > non-semantic change in LLVM: > >     --- a/llvm/lib/Analysis/VectorUtils.cpp >     +++ b/llvm/lib/Analysis/VectorUtils.cpp >     @@ -642,8 +642,8 @@ MDNode *llvm::uniteAccessGroups(MDNode > *AccGroups1, MDNode *AccGroups2) { >          return AccGroups1;

...e BPI? > > Nope, not implemented right now. > One of the problems is that even loop canonicalization passes run at the > start of loop pass manager dont preserve it > (and at least LoopSimplifyCFG does change control flow). > > > In buildFunctionSimplificationPipeline (where LoopFullUnrollPass is added > as in the sketch), LateLoopOptimizationsEPCallbacks > and LoopOptimizerEndEPCallbacks seem to allow some arbitrary loop passes to > be inserted into the pipelines (via flags)? > > I wonder how hard it'd be to teach all the relevant loop passes to > preserve BFI (or...

...t; One of the problems is that even loop canonicalization passes > run at the start of loop pass manager dont preserve it > (and at least LoopSimplifyCFG does change control flow). >> >> In buildFunctionSimplificationPipeline >> (where LoopFullUnrollPass is added as in the sketch), >> LateLoopOptimizationsEPCallbacks >> and LoopOptimizerEndEPCallbacks seem to allow some arbitrary >> loop passes to be inserted into the pipelines (via flags)? >> >> I wonder how hard it'd be to teach al...

...that need to be pipelined > to preserve BPI (or any other module/function-level analyses) similar to > how they preserve DominatorTree and > other "LoopStandard" analyses. > Is this implemented - do the loop passes preserve BPI? In buildFunctionSimplificationPipeline (where LoopFullUnrollPass is added as in the sketch), LateLoopOptimizationsEPCallbacks and LoopOptimizerEndEPCallbacks seem to allow some arbitrary loop passes to be inserted into the pipelines (via flags)? I wonder how hard it'd be to teach all the relevant loop passes to preserve BFI (or BPI).. > It seems that f...

...at even loop canonicalization >> passes run at the start of loop pass manager dont preserve it >> (and at least LoopSimplifyCFG does change control flow). >>> >>> In buildFunctionSimplificationPipeline >>> (where LoopFullUnrollPass is added as in the sketch), >>> LateLoopOptimizationsEPCallbacks >>> and LoopOptimizerEndEPCallbacks seem to allow some >>> arbitrary loop passes to be inserted into the pipelines >>> (via flags)? >>> >&...

...run at the start of loop >>> pass manager dont preserve it >>> (and at least LoopSimplifyCFG does change control flow). >>>> >>>> In buildFunctionSimplificationPipeline >>>> (where LoopFullUnrollPass is added as in the >>>> sketch), LateLoopOptimizationsEPCallbacks >>>> and LoopOptimizerEndEPCallbacks seem to allow some >>>> arbitrary loop passes to be inserted into the >>>> pipelines...

Hi all, To implement more profile-guided optimizations, we’d like to use ProfileSummaryInfo (PSI) and BlockFrequencyInfo (BFI) from more passes of various types, under the new pass manager. The following is what we came up with. Would appreciate feedback. Thanks. Issue It’s not obvious (to me) how to best do this, given that we cannot request an outer-scope analysis result from an inner-scope