search for: assumptioncach

Hi all, Guard intrinsics[0] are similar in nature to Assume intrinsics, in that the condition passed to a guard intrinsic call is known to be true at locations dominated (but *not* post-dominated) by the call[1]. I'd like to re-use the AssumptionCache infrastructure that already exists to teach the mid level optimizer to exploit this property. The steps I want to take are (not necessarily in this order or split up this way): - Rename AssumptionCache to AxiomCache (or something similar) - Maintain two lists in AxiomCache, one for assumptio...

Hi all, We have recently encountered a problem with AssumptionCache that it does not get updated when a block with llvm.assume calls gets outlined by the CodeExtractor. As a result we end up with stale references to the llvm.assume calls that were moved to the outlined function in the parent function's cache. The problem can be reproduced on the attached file...

Hi Hal, On 1/16/19 6:59 PM, Dmitriev, Serguei N via llvm-dev wrote: Hi all, We have recently encountered a problem with AssumptionCache that it does not get updated when a block with llvm.assume calls gets outlined by the CodeExtractor. As a result we end up with stale references to the llvm.assume calls that were moved to the outlined function in the parent function's cache. The problem can be reproduced on the attached file...

...anchProbabilityAnalysis: Stores no pointers to other analyses. (uses > LoopInfo to "recalculate" though) > DominatorTreeAnalysis: Stores no pointers to other analyses. > PostDominatorTreeAnalysis: Stores no pointers to other analyses. > DemandedBitsAnalysis: Stores pointers to AssumptionCache and DominatorTree > DominanceFrontierAnalysis: Stores no pointers to other analyses. > (uses DominatorTreeAnalysis for "recalculate" though). > LoopInfo: Uses DominatorTreeAnalysis for "recalculate" but stores no > pointers. > LazyValueAnalysis: Stores pointers t...

On Tue, Jul 12, 2016 at 11:34 PM Sean Silva <chisophugis at gmail.com> wrote: > On Tue, Jul 12, 2016 at 11:32 PM, Xinliang David Li <davidxl at google.com> > wrote: > >> >> >> On Tue, Jul 12, 2016 at 10:57 PM, Chandler Carruth <chandlerc at gmail.com> >> wrote: >> >>> Yea, this is a nasty problem. >>> >>> One

...DominatorTree DT = DominatorTree(); DT.recalculate(*func); DT.updateDFSNumbers(); LoopInfoBase<BasicBlock, Loop> LIB; LIB.releaseMemory(); LIB.analyze(DT); for(auto&bb :*func){ Loop * L = LIB.getLoopFor(&bb); if(L != nullptr){ AssumptionCache AC = AssumptionCache(*bb.getParent()); Triple MT(llvm::sys::getDefaultTargetTriple()); TargetLibraryInfoImpl TLII(MT); TargetLibraryInfoWrapperPass TLI = TargetLibraryInfoWrapperPass(TLII); LoopInfo LI = LoopInfo(DT); LI.analyze(DT);...

...no pointers to other analyses. (uses >>> LoopInfo to "recalculate" though) >>> DominatorTreeAnalysis: Stores no pointers to other analyses. >>> PostDominatorTreeAnalysis: Stores no pointers to other analyses. >>> DemandedBitsAnalysis: Stores pointers to AssumptionCache >>> and DominatorTree >>> DominanceFrontierAnalysis: Stores no pointers to other analyses. >>> (uses DominatorTreeAnalysis for "recalculate" though). >>> LoopInfo: Uses DominatorTreeAnalysis for "recalculate" but stores no >>> pointe...

...analyses. > > > > > > > > > > > > > > > PostDominatorTreeAnalysis: Stores no pointers to other > > > > > analyses. > > > > > > > > > > > > > > > DemandedBitsAnalysis: Stores pointers to AssumptionCache and > > > > > DominatorTree > > > > > > > > > > > > > > > DominanceFrontierAnalysis: Stores no pointers to other > > > > > analyses. > > > > > (uses DominatorTreeAnalysis for "recalculate" thou...

...t; > > PostDominatorTreeAnalysis: Stores no pointers to other > > > > > > > analyses. > > > > > > > > > > > > > > > > > > > > > > > > > > > > DemandedBitsAnalysis: Stores pointers to AssumptionCache > > > > > > > and > > > > > > > DominatorTree > > > > > > > > > > > > > > > > > > > > > > > > > > > > DominanceFrontierAnalysis: Stores no pointers to other > &gt...

...uses >>>>> LoopInfo to "recalculate" though) >>>>> DominatorTreeAnalysis: Stores no pointers to other analyses. >>>>> PostDominatorTreeAnalysis: Stores no pointers to other analyses. >>>>> DemandedBitsAnalysis: Stores pointers to AssumptionCache >>>>> and DominatorTree >>>>> DominanceFrontierAnalysis: Stores no pointers to other analyses. >>>>> (uses DominatorTreeAnalysis for "recalculate" though). >>>>> LoopInfo: Uses DominatorTreeAnalysis for "recalculate" b...

...t; > > PostDominatorTreeAnalysis: Stores no pointers to other > > > > > > > analyses. > > > > > > > > > > > > > > > > > > > > > > > > > > > > DemandedBitsAnalysis: Stores pointers to AssumptionCache > > > > > > > and > > > > > > > DominatorTree > > > > > > > > > > > > > > > > > > > > > > > > > > > > DominanceFrontierAnalysis: Stores no pointers to other > &gt...

...gt;> (uses LoopInfo to "recalculate" though) >>>>>> DominatorTreeAnalysis: Stores no pointers to other analyses. >>>>>> PostDominatorTreeAnalysis: Stores no pointers to other analyses. >>>>>> DemandedBitsAnalysis: Stores pointers to AssumptionCache >>>>>> and DominatorTree >>>>>> DominanceFrontierAnalysis: Stores no pointers to other analyses. >>>>>> (uses DominatorTreeAnalysis for "recalculate" though). >>>>>> LoopInfo: Uses DominatorTreeAnalysis for "rec...

...ential use case for getting an analysis outside of something in, or called by, run()? > One annoying problem is that I think that the dependency links will > need to be bidirectional. To use the example analysis cache from my > other post: > (AssumptionAnalysis, function @bar) -> (AssumptionCache for @bar, > [(SomeModuleAnalysis, module TheModule)]) > (AssumptionAnalysis, function @baz) -> (AssumptionCache for @baz, > [(SomeModuleAnalysis, module TheModule)]) > (SomeModuleAnalysis, module TheModule) -> (SomeModuleAnalysisResult > for TheModule, [(SomeFunctionAnalysis,...

...chProbabilityAnalysis: Stores no pointers to other analyses. > (uses LoopInfo to "recalculate" though) > DominatorTreeAnalysis: Stores no pointers to other analyses. > PostDominatorTreeAnalysis: Stores no pointers to other analyses. > DemandedBitsAnalysis: Stores pointers to AssumptionCache and > DominatorTree > DominanceFrontierAnalysis: Stores no pointers to other analyses. > (uses DominatorTreeAnalysis for "recalculate" though). > LoopInfo: Uses DominatorTreeAnalysis for "recalculate" but stores no > pointers. > LazyValueAnalysis: Stores po...

...s LoopInfo to "recalculate" though) >>>>>>> DominatorTreeAnalysis: Stores no pointers to other analyses. >>>>>>> PostDominatorTreeAnalysis: Stores no pointers to other analyses. >>>>>>> DemandedBitsAnalysis: Stores pointers to AssumptionCache >>>>>>> and DominatorTree >>>>>>> DominanceFrontierAnalysis: Stores no pointers to other analyses. >>>>>>> (uses DominatorTreeAnalysis for "recalculate" though). >>>>>>> LoopInfo: Uses DominatorTreeAnalys...

...;F) -> LoopInfo & { return this->getAnalysis<LoopInfoWrapperPass>(F).getLoopInfo(); }; auto SCEVGetter = [this] (Function &F) -> ScalarEvolution & { return this->getAnalysis<ScalarEvolutionWrapperPass>(F).getSE(); }; auto AssumptionCacheGetter = [this] (Function &F) -> AssumptionCache & { return this->getAnalysis<AssumptionCacheTracker>().getAssumptionCache(F); }; auto OREGetter = [this] (Function &F) -> OptimizationRemarkEmitter & { return this->...

...cked via re-entrance > to get{,Cached}Result); is this a reasonable restriction? > > > One annoying problem is that I think that the dependency links will need > to be bidirectional. To use the example analysis cache from my other post: > (AssumptionAnalysis, function @bar) -> (AssumptionCache for @bar, > [(SomeModuleAnalysis, module TheModule)]) > (AssumptionAnalysis, function @baz) -> (AssumptionCache for @baz, > [(SomeModuleAnalysis, module TheModule)]) > (SomeModuleAnalysis, module TheModule) -> (SomeModuleAnalysisResult for > TheModule, [(SomeFunctionAnalysis,...

...#9 0x00007fd9397d3b4b llvm::Value::replaceAllUsesWith(llvm::Value*) /llvm/lib/IR/Value.cpp:383:0 #10 0x00007fd9372f7ba1 llvm::UnrollLoop(llvm::Loop*, unsigned int, unsigned int, bool, bool, bool, unsigned int, llvm::LoopInfo*, llvm::ScalarEvolution*, llvm::DominatorTree*, llvm::AssumptionCache*, bool) /llvm/lib/Transforms/Utils #11 0x00007fd937ec812d tryToUnrollLoop(llvm::Loop*, llvm::DominatorTree&, llvm::LoopInfo*, llvm::ScalarEvolution*, llvm::TargetTransformInfo const&, llvm::AssumptionCache&, bool, llvm::Optional<unsigned int>, llvm::Optional<unsigne...

...n approach for, for the sake of eliminating some bounds checks in Rust that the Go compiler is apparently able to eliminate: https://github.com/rust-lang/rust/issues/35981 I'll quote my questions about the possible implementation below and try to add some more context. > DominatorTree and AssumptionCache do seem to be sufficient and already > present. computeOverflowForSignedAdd and computeOverflowForUnsignedAdd > look like the kind of places to extend with this analysis based on > that info. ValueTracking has access to DominatorTree and AssumptionCache information, and provides the n...

...Width, IC, > &LVL, &CM); > > If we imagine that over time it evolves such that 50% of the variables have been renamed to camelBack versions of the type names, then it will look like this: > > InnerLoopVectorizer LB(loop, PSE, loopInfo, DT, targetLibraryInfo, TTI, > assumptionCache, ORE, vectorizationFactor.Width, IC, > &loopVectorizationLegality, &CM); Hold on... The change from UpperCamel to lowerCamel should be separate from going from X to somethingOtherName. It seems like in this example, TLI is changed to targetLibraryInfo for the purpose of having a...