search for: loopaccessinfo

...p;, llvm::ScalarEvolution*, llvm::Loop*, llvm::DenseMap<llvm::Value const*, llvm::Value*, llvm::DenseMapInfo<llvm::Value const*>, llvm::detail::DenseMapPair<llvm::Value const*, llvm::Value*> > const&, bool) $SRC/llvm-project/llvm/lib/Analysis/LoopAccessAnalysis.cpp:830:3 llvm::LoopAccessInfo::analyzeLoop(llvm::AAResults*, llvm::LoopInfo*, llvm::TargetLibraryInfo const*, llvm::DominatorTree*) $SRC/llvm-project/llvm/lib/Analysis/LoopAccessAnalysis.cpp:2038:8 llvm::LoopAccessInfo::LoopAccessInfo(llvm::Loop*, llvm::ScalarEvolution*, llvm::TargetLibraryInfo const*, llvm::AAResults*, llvm::D...

...oopInfo &li = getAnalysis<LoopInfoWrapperPass>().getLoopInfo(); LoopAccessLegacyAnalysis &lala = getAnalysis<LoopAccessLegacyAnalysis>(); for(LoopInfo::iterator lp = li.begin(); lp != li.end(); lp++) { Loop *loop = *lp; const LoopAccessInfo &lai = lala.getInfo(loop); // need help here // I can’t get any information from the LoopAccessInfo instance. errs()<<lai.getNumLoads(); // return 0 } } // register static RegisterPass<SkeletonPass> X("test", "test for using the exist...

...p;, llvm::ScalarEvolution*, llvm::Loop*, llvm::DenseMap<llvm::Value const*, llvm::Value*, llvm::DenseMapInfo<llvm::Value const*>, llvm::detail::DenseMapPair<llvm::Value const*, llvm::Value*> > const&, bool) $SRC/llvm-project/llvm/lib/Analysis/LoopAccessAnalysis.cpp:830:3 llvm::LoopAccessInfo::analyzeLoop(llvm::AAResults*, llvm::LoopInfo*, llvm::TargetLibraryInfo const*, llvm::DominatorTree*) $SRC/llvm-project/llvm/lib/Analysis/LoopAccessAnalysis.cpp:2038:8 llvm::LoopAccessInfo::LoopAccessInfo(llvm::Loop*, llvm::ScalarEvolution*, llvm::TargetLibraryInfo const*, llvm::AAResults*, llvm::D...

...er in the tree or the WIP patch for the loop-distribution pass in http://reviews.llvm.org/D6930 <http://reviews.llvm.org/D6930>. > > Please let me know if you have any questions. > > I have gone through current LAA, found few gaps for reusing it. > > i.e. > 928 void LoopAccessInfo::analyzeLoop(const ValueToValueMap &Strides) { > 1029 if (isUniform(Ptr)) { > 1030 emitAnalysis( > 1031 LoopAccessReport(ST) > 1032 << "write to a loop invariant address could not be vectorized"); > 1033 DEBUG(dbgs() << &q...

...er in the tree or the WIP patch for the loop-distribution pass in http://reviews.llvm.org/D6930 <http://reviews.llvm.org/D6930>. > > Please let me know if you have any questions. > > I have gone through current LAA, found few gaps for reusing it. > > i.e. > 928 void LoopAccessInfo::analyzeLoop(const ValueToValueMap &Strides) { > 1029 if (isUniform(Ptr)) { > 1030 emitAnalysis( > 1031 LoopAccessReport(ST) > 1032 << "write to a loop invariant address could not be vectorized"); > 1033 DEBUG(dbgs() << &q...

...opInfoWrapperPass>().getLoopInfo(); > LoopAccessLegacyAnalysis &lala = getAnalysis< > LoopAccessLegacyAnalysis>(); > > for(LoopInfo::iterator lp = li.begin(); lp != li.end(); lp++) > { > Loop *loop = *lp; > const LoopAccessInfo &lai = lala.getInfo(loop); > > // need help here > // I can’t get any information from the LoopAccessInfo > instance. > errs()<<lai.getNumLoads(); // return 0 > } > } > > > // register > static RegisterPa...

...er in the tree or the WIP patch for the loop-distribution pass in http://reviews.llvm.org/D6930 <http://reviews.llvm.org/D6930>. > > Please let me know if you have any questions. > > I have gone through current LAA, found few gaps for reusing it. > > i.e. > 928 void LoopAccessInfo::analyzeLoop(const ValueToValueMap &Strides) { > 1029 if (isUniform(Ptr)) { > 1030 emitAnalysis( > 1031 LoopAccessReport(ST) > 1032 << "write to a loop invariant address could not be vectorized"); > 1033 DEBUG(dbgs() << &q...

...ers into another analysis's data structures. To be concrete, holding a pointer to ScalarEvolution is not a fundamental problem because we could make the analysis reacquire the pointer at the start of every query. Holding SCEV* is the problem. > > Looks like SCEV* at least is held only by LoopAccessInfo. (Looks like LAA holds Loop* too) > > Note that Loop (and SCC) are somewhat special as they are IRUnitTs and might as a consequence be more reasonable to hold on to and expect definitive invalidation to occur. But I say "might". I think this will be case-by-case depending on how th...

...a >> structures. To be concrete, holding a pointer to ScalarEvolution is not a >> fundamental problem because we could make the analysis reacquire the >> pointer at the start of every query. Holding SCEV* is the problem. >> > > Looks like SCEV* at least is held only by LoopAccessInfo. (Looks like LAA > holds Loop* too) > Note that Loop (and SCC) are somewhat special as they are IRUnitTs and might as a consequence be more reasonable to hold on to and expect definitive invalidation to occur. But I say "might". I think this will be case-by-case depending on how th...

...fo &li = getAnalysis<LoopInfoWrapperPass>().getLoopInfo(); LoopAccessLegacyAnalysis &lala = getAnalysis<LoopAccessLegacyAnalysis>(); for(LoopInfo::iterator lp = li.begin(); lp != li.end(); lp++) { Loop *loop = *lp; const LoopAccessInfo &lai = lala.getInfo(loop); // need help here // I can’t get any information from the LoopAccessInfo instance. errs()<<lai.getNumLoads(); // return 0 } } // register static RegisterPass<SkeletonPass> X("test", "test for using the exis...

...ied your patch to cope with both kinds of dependencies in the ForwardingCandidate class, but the way the pass gathers informations only brings RAW dependencies: const auto *Deps = LAI.getDepChecker().getDependences(); if (!Deps) return Candidates; If I add RAR dependency checking on LoopAccessInfo, that'll break everything else that depends on it, and if I scan the basic blocks for RAR dependency in LLE itself, it would be moving the logic away from its rightful place. I'm thinking of renaming getDependencies() to something like getStoreToLoadDeps() and add a getLoadToLoadDeps(). Do...

...hard-dependency. The soft dependency refers to the case where analysis 'A' >> depends on 'B' during computation, but does not need 'B' once it is >> computed. >> >> There are actually quite a few examples of hard-dependency case. For >> instance LoopAccessInfo, LazyValueInfo etc which hold references to other >> analyses. >> >> Problem involving hard-dependency is actually easier to detect, as it is >> usually a compile time problem. Issues involving soft dependencies are more >> subtle and can lead to wrong code gen. >&g...

...s type of dependencies (holding references) hard-dependency. The soft dependency refers to the case where analysis 'A' depends on 'B' during computation, but does not need 'B' once it is computed. There are actually quite a few examples of hard-dependency case. For instance LoopAccessInfo, LazyValueInfo etc which hold references to other analyses. Problem involving hard-dependency is actually easier to detect, as it is usually a compile time problem. Issues involving soft dependencies are more subtle and can lead to wrong code gen. David > > Some ideas about mitigating an...

> On Mar 5, 2015, at 10:33 PM, Nema, Ashutosh <Ashutosh.Nema at amd.com> wrote: > > > I am about to post the patches to make LAA suitable for Loop Distribution. As you will hopefully find this will make the LAA more generic. I will cc you on the patches. > > Sure Adam. > > RuntimeCheckEmitter > “RuntimeCheckEmitter::addRuntimeCheck” > While creating

...ing computation, but does not > > > > need > > > > 'B' once it is computed. > > > > > > > > > > There are actually quite a few examples of hard-dependency > > > > case. > > > > For > > > > instance LoopAccessInfo, LazyValueInfo etc which hold > > > > references > > > > to > > > > other analyses. > > > > > > > > > > Problem involving hard-dependency is actually easier to detect, > > > > as > > > > it > > >...

...hard-dependency. The soft dependency refers to the case where analysis 'A' >> depends on 'B' during computation, but does not need 'B' once it is >> computed. >> >> There are actually quite a few examples of hard-dependency case. For >> instance LoopAccessInfo, LazyValueInfo etc which hold references to other >> analyses. >> >> Problem involving hard-dependency is actually easier to detect, as it is >> usually a compile time problem. Issues involving soft dependencies are more >> subtle and can lead to wrong code gen. >&g...

...ers to the case where analysis 'A' >>>> depends on 'B' during computation, but does not need 'B' once it is >>>> computed. >>>> >>>> There are actually quite a few examples of hard-dependency case. For >>>> instance LoopAccessInfo, LazyValueInfo etc which hold references to other >>>> analyses. >>>> >>>> Problem involving hard-dependency is actually easier to detect, as it >>>> is usually a compile time problem. Issues involving soft dependencies are >>>> more subtl...

...9; >>>>>> depends on 'B' during computation, but does not need 'B' once it is >>>>>> computed. >>>>>> >>>>>> There are actually quite a few examples of hard-dependency case. For >>>>>> instance LoopAccessInfo, LazyValueInfo etc which hold references to other >>>>>> analyses. >>>>>> >>>>>> Problem involving hard-dependency is actually easier to detect, as it >>>>>> is usually a compile time problem. Issues involving soft dependencies...

Hello, Yes? Where is allActive defined, I couldn't find it. Basically, a BB is control divergent if it's execution depends on a branch that itself depends on a divergent ssa value. On Fri, Jul 21, 2017 at 4:13 PM, Zaks, Ayal <ayal.zaks at intel.com> wrote: > What would be the definition of “isControlDivergent(BasicBlock*)”; the > complementary of “allActive(BasicBlock*)” –

...nds on 'B' during computation, but does not need 'B' once it is >>>>>>>> computed. >>>>>>>> >>>>>>>> There are actually quite a few examples of hard-dependency case. >>>>>>>> For instance LoopAccessInfo, LazyValueInfo etc which hold references to >>>>>>>> other analyses. >>>>>>>> >>>>>>>> Problem involving hard-dependency is actually easier to detect, as >>>>>>>> it is usually a compile time problem. Is...