search for: loopstandardanalysisresults

...oblem. The problem is due to the existing hard dependency of IRCE on BranchProbability analysis. If I understand it right, 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 'i...

...mode, the crash hit at the same assertion: /usr/local/include/llvm/IR/PassManager.h:689: typename PassT::Result& llvm::AnalysisManager<IRUnitT, ExtraArgTs>::getResult(IRUnitT&, ExtraArgTs ...) [with PassT = llvm::InnerAnalysisManagerProxy<llvm::AnalysisManager<llvm::Loop, llvm::LoopStandardAnalysisResults&>, llvm::Function>; IRUnitT = llvm::Function; ExtraArgTs = {}; typename PassT::Result = llvm::InnerAnalysisManagerProxy<llvm::AnalysisManager<llvm::Loop, llvm::LoopStandardAnalysisResults&>, llvm::Function>::Result]: Assertion `AnalysisPasses.count(PassT::ID()) &&...

...'s a good point, we can make ScalarEvolution optional for LoopNest. > Currently, the only use case is to check if the loop nest is perfect, which > can provide a more conservative result if ScalarEvolution is not given. > Having said that, ScalarEvolution is one of the analyses in > LoopStandardAnalysisResults, so all LoopPasses already have access to > ScalarEvolution. > LoopNest provides some useful utilities, although it is still not at a > manual phrase. > My personal opinion is all the mechanism of the LoopNest, e.g. LoopNestPassManager, > LPMUpdater, etc, should operates on Loop. Whi...

Hi, Thanks for your help! I've checked the sources that you mentioned. Currently, I think that I would need to implement a FunctionToLoopNestPassAdaptor which is essentially the same as the FunctionToLoopPassAdaptor but operates only on LI.getTopLevelLoops(). We might also need a LNPMUpdater (LoopNestPassManagerUpdater) which disallows adding inner-loops back into the pipeline, and

This question has been submitted to stackoverflow (https://stackoverflow.com/questions/51934964/function-optimization-pass) but someone suggested me that it should be submitted to llvm-dev mailing list instead. I'm sorry for the duplication. I am trying to use PassBulider and FunctionPassManager || to optimize a function in a module, what I have done is: mod = ...load module from LLVM

...ne interruptions and potential > invalidation/recomputation of BFI between the loop passes. We detect > PGO based on whether PSI has profile summary info. (For the old pass > manager, implement a similar approach by using LazyBlockFrequencyInfo.) There is already an optional analysis in LoopStandardAnalysisResults - MemorySSA. We can do the same for BFI/BPI. And, yes - preserving those through loop passes is a cornerstone to this approach. > > - Add a new proxy ModuleAnalysisManagerLoopProxy for a loop pass to be > able to get to the ModuleAnalysisManager in one step and PSI through it. This is j...

Hi, I'm a college student who is quite new to the community and is interested in contributing to the LLVM project. Although I haven't applied to GSoC, I notice that the project "Create LoopNestPass" seems to be unassigned. So I'm curious whether anyone is currently working on it, and if not, is it possible for me to work on it as a side-project? I've been programming in

...chedResult<ProfileSummaryAnalysis>(*F.getParent()); >   ... > > > AFAICT, adding ModuleAnalysisManagerLoopProxy seems to be as simple as: > > /// A proxy from a \c ModuleAnalysisManager to a \c Loop. > typedef OuterAnalysisManagerProxy<ModuleAnalysisManager, Loop, > LoopStandardAnalysisResults &> > ModuleAnalysisManagerLoopProxy; It also needs to be added to PassBuilder::crossRegisterProxies... But yes, that appears to be a required action. regards,   Fedor. > > > > regards, >   Fedor. >> >> >> >> >> On Mon, Mar 4, 2019...

Here's a sketch of the proposed approach for just one pass (but imagine more) https://reviews.llvm.org/D58845 On Fri, Mar 1, 2019 at 12:54 PM Fedor Sergeev via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 2/28/19 12:47 AM, Hiroshi Yamauchi via llvm-dev wrote: > > Hi all, > > To implement more profile-guided optimizations, we’d like to use > ProfileSummaryInfo

On 3/4/19 10:49 PM, Hiroshi Yamauchi wrote: > > > On Mon, Mar 4, 2019 at 10:55 AM Hiroshi Yamauchi <yamauchi at google.com > <mailto:yamauchi at google.com>> wrote: > > > > On Sat, Mar 2, 2019 at 12:58 AM Fedor Sergeev > <fedor.sergeev at azul.com <mailto:fedor.sergeev at azul.com>> wrote: > > > > On 3/2/19 2:38 AM,