search for: getcachedresult

Hi, mustPreserveAnalysisID(LCSSAID) cannot be used with the new pass manager, so what is the right way for querying it? FunctionAnalysisManager::getCachedResult<LCSSAPass>(F) will not work, since LCSSAPass does not have a result. Moreover, it is not an analysis :) Thanks, Slava -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190206/d0d74674/attachment.html&g...

...ction &F,                                        AnalysisManager<Function> &AM) {   auto &AC = AM.getResult<AssumptionAnalysis>(F);   auto &DT = AM.getResult<DominatorTreeAnalysis>(F);   auto &TLI = AM.getResult<TargetLibraryAnalysis>(F);   auto *LI = AM.getCachedResult<LoopAnalysis>(F);   // FIXME: The AliasAnalysis is not yet supported in the new pass manager Thanks, Welson -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170128/8546aca5/attachment.html>

...> ModuleAnalysisManager and PSI (see below.) This actually happens in my > experiment. > > SomeLoopPass::run(Loop &L, LoopAnalysisManager &LAM, …) { > auto &FAM = LAM.getResult<FunctionAnalysisManagerLoopProxy>(L, > AR).getManager(); > auto *MAMProxy = FAM.getCachedResult<ModuleAnalysisManagerFunctionProxy>( >   L.getHeader()->getParent()); *// Can be null* Oh... well... > If (MAMProxy) { > auto &MAM = MAMProxy->getManager(); > auto *PSI = MAM.getCachedResult<ProfileSummaryAnalysis>(*F.getParent()); >   } else { > *// Can'...

...); > > ... > } > > > include/IR/Canonicalization.h: > > template <typename CanonicalizationT, typename IRUnitT> > void canonicalizeIR(IRUnitT &IR, AnalysisManager &AM) { > using IndicatorT = typename CanonicalizationT::IndicatorAnalysis; > if (AM.getCachedResult<http://AM.getCachedResult><IndicatorT>(IR)) > return; > CanonicalizationT C; > PreservedAnalysis PA = C.run<http://C.run>(IR, AM); > AM.invalidate<http://AM.invalidate>(IR, PA); > (void)AM.getResult<http://AM.getResult><IndicatorT>(IR);...

...add the analysis pass right at the beginning of the pass pipeline. The new analysis pass holds the dump messages throughout the pass pipeline. If you would like to dump messages from some pass, you would obtain the result of DumpAccumulator in the pass: DumpAccumulator::Result *DAR = MAMProxy.getCachedResult<DumpAccumulator>(M); Then dump messages: if (DAR) { DAR->Message += "Processing "; DAR->Message += F.getName(); DAR->Message += "\n"; } AsmPrinter ---------- We dump the messages from DumpAccumulator into a section called ".llvm_dump"...

...e summary. >>> >>> >>> regards, >>>   Fedor. >>> >>>> >>>> >>>> [1] We cannot call AnalysisManager::getResult for >>>> an outer scope but only getCachedResult. Probably >>>> because of potential pipelining or concurrency issues. >>>> [2] For example, potentially breaking up multiple >>>> pipelined loop passes and insert >>>> RequireAnalysisPass...

...ht, in a new pass manager there are only two ways for loop analysis to ask for the result of an "outer" (function/module-level) analysis:   - get it from a predefined LoopStandardAnalysisResults set     BPI is not there, so it unsuitable for me right now   - query a cached result via getCachedResult of an outer analysis manager proxy     only works if somebody already scheduled the analysis I followed the cached-result way and that essentially means that for every presence of 'irce' in a pipeline I have to insert 'require<branch-prob>' before it. It does not look like...

...ine.  The new >> analysis pass holds the dump messages throughout the pass pipeline. >> >> If you would like to dump messages from some pass, you would obtain >> the result of DumpAccumulator in the pass: >> >>    DumpAccumulator::Result *DAR = >> MAMProxy.getCachedResult<DumpAccumulator>(M); >> >> Then dump messages: >> >>    if (DAR) { >>      DAR->Message += "Processing "; >>      DAR->Message += F.getName(); >>      DAR->Message += "\n"; >>    } >> >> AsmPrinter >&g...

...ude/IR/Canonicalization.h: >> > >> > template <typename CanonicalizationT, typename IRUnitT> >> > void canonicalizeIR(IRUnitT &IR, AnalysisManager &AM) { >> > using IndicatorT = typename CanonicalizationT::IndicatorAnalysis; >> > if (AM.getCachedResult<IndicatorT>(IR)) >> > return; >> > CanonicalizationT C; >> > PreservedAnalysis PA = C.run(IR, AM); >> > AM.invalidate(IR, PA); >> > (void)AM.getResult<IndicatorT>(IR); >> > } >> > >> > ``` >> >...

...lazy or not, new or old (pass manager). Another assumption is that it'd be cheap and safe to unconditionally depend on PSI or check the module's profile summary. > regards, > Fedor. > > > > [1] We cannot call AnalysisManager::getResult for an outer scope but only > getCachedResult. Probably because of potential pipelining or concurrency > issues. > [2] For example, potentially breaking up multiple pipelined loop passes > and insert RequireAnalysisPass<BlockFrequencyAnalysis> in front of each of > them. > [3] For example, -fprofile-instr-use and -fprofile...

...) With this, we wouldn’t need to conditionally build pass pipelines and may work for the new pass manager. But a similar wouldn’t work for the old pass manager because we cannot conditionally depend on an analysis under it. [1] We cannot call AnalysisManager::getResult for an outer scope but only getCachedResult. Probably because of potential pipelining or concurrency issues. [2] For example, potentially breaking up multiple pipelined loop passes and insert RequireAnalysisPass<BlockFrequencyAnalysis> in front of each of them. [3] For example, -fprofile-instr-use and -fprofile-sample-use aren’t presen...

...pipeline. The new > > analysis pass holds the dump messages throughout the pass pipeline. > > > > If you would like to dump messages from some pass, you would obtain > > the result of DumpAccumulator in the pass: > > > > DumpAccumulator::Result *DAR = MAMProxy.getCachedResult<DumpAccumulator>(M); > > > > Then dump messages: > > > > if (DAR) { > > DAR->Message += "Processing "; > > DAR->Message += F.getName(); > > DAR->Message += "\n"; > > } > > > > AsmPrinter &...

...er > assumption is that it'd be cheap and safe to unconditionally depend on > PSI or check the module's profile summary. > > >> regards, >> Fedor. >> >> >> >> [1] We cannot call AnalysisManager::getResult for an outer scope but only >> getCachedResult. Probably because of potential pipelining or concurrency >> issues. >> [2] For example, potentially breaking up multiple pipelined loop passes >> and insert RequireAnalysisPass<BlockFrequencyAnalysis> in front of each of >> them. >> [3] For example, -fprofile-ins...

...SI or >> check the module's profile summary. >> >> >> regards, >>   Fedor. >> >>> >>> >>> [1] We cannot call AnalysisManager::getResult for an >>> outer scope but only getCachedResult. Probably because >>> of potential pipelining or concurrency issues. >>> [2] For example, potentially breaking up multiple >>> pipelined loop passes and insert >>> RequireAnalysisPass<BlockFrequencyAnalysis> i...

Hi Sean, Thanks for writing all of this up. I'll go back to my previous position: we need a general dependency graph built as the analysis cache is used. It should have the following properties: 1. When we call getResult or getCachedResult on an analysis manager, we record a dependency of the current pass on the returned result. 2. This dependency needs to be stored such that it can be used to invalidate the current result when the returned result is invalidates and so that the dependency can be deleted when the current result is in...

...ks for writing all of this up. I'll go back to my previous > > position: we need a general dependency graph built as the analysis > > cache is used. > > I share the same feeling. > > It should have the following properties: > > > 1. When we call getResult or getCachedResult on an analysis > > manager, > > we record a dependency of the current pass on the returned result. > > Because of the hard vs soft dependency, I'm not sure if this has to > be implicit or if it'd be better made explicit though, i.e. with a > separate API call. Can...

...wrote: > > Hi Sean, > > > Thanks for writing all of this up. I'll go back to my previous > > position: we need a general dependency graph built as the analysis > > cache is used. It should have the following properties: > > > 1. When we call getResult or getCachedResult on an analysis > > manager, > > we record a dependency of the current pass on the returned result. > > > 2. This dependency needs to be stored such that it can be used to > > invalidate the current result when the returned result is > > invalidates and so that the...

...e: > >> Hi Sean, >> >> Thanks for writing all of this up. I'll go back to my previous position: >> we need a general dependency graph built as the analysis cache is used. It >> should have the following properties: >> >> 1. When we call getResult or getCachedResult on an analysis manager, we >> record a dependency of the current pass on the returned result. >> 2. This dependency needs to be stored such that it can be used to >> invalidate the current result when the returned result is invalidates and >> so that the dependency can be d...

..., >>> >>> Thanks for writing all of this up. I'll go back to my previous position: >>> we need a general dependency graph built as the analysis cache is used. It >>> should have the following properties: >>> >>> 1. When we call getResult or getCachedResult on an analysis manager, we >>> record a dependency of the current pass on the returned result. >>> 2. This dependency needs to be stored such that it can be used to >>> invalidate the current result when the returned result is invalidates and >>> so that the dep...

The more closely I look at this, the more it seems like there may be a useful incremental step in the transition to the new PM: use the new PM analysis machinery in the old PM. If this is possible, it will simplify the old PM and (hopefully) allow an incremental transition to the new PM instead of a flag day transition for the switch. I.e., AFAICT, the new PM transition is essentially about 2