Displaying 10 results from an estimated 10 matches for "analyzeloop".
2019 May 10
2
[Pipeliner] MachinePipeliner TargetInstrInfo hooks need more information?
...ike Hexagon however, our backend doesn't generate hardware loop
instructions and so all our loops are a combination of induction
variables, comparisons and branches. So when it came to implementing
reduceLoopCount for our TargetInstrInfo, we found that we didn't have
enough information from analyzeLoop to reduce the loops.
Currently the signatures look like this:
bool analyzeLoop(MachineLoop &L, MachineInstr *&IndVarInst,
MachineInstr *&CmpInst)
unsigned TargetInstrInfo::reduceLoopCount(MachineBasicBlock &MBB,
MachineInstr *IndVar,...
2015 Mar 19
2
[LLVMdev] RFC: Loop versioning for LICM
...r 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() << "LAA: We d...
2015 Mar 20
2
[LLVMdev] RFC: Loop versioning for LICM
...r 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() << "LAA: We d...
2015 Mar 24
3
[LLVMdev] RFC: Loop versioning for LICM
...r 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() << "LAA: We d...
2015 Mar 11
2
[LLVMdev] RFC: Loop versioning for LICM
...t could unnecessarily slow things down.
>
>
> I just wanted to keep a flexibility open.
> We can give a try to LoopVersioning by keeping point 1 & 3 checks. but I’m not sure about point 2.
> Will give a try to your upcoming patch.
>
>
>
> LoopAccessAnalysis::analyzeLoop
> Here again its very specific to LoopVectorizer.
> The way it handles stores & loads may not be appreciated by other optimization
> expecting other treatment. I suggest we should think on flexibility for user to
> override load & store handling. We can provide virtual methods...
2015 Mar 04
2
[LLVMdev] RFC: Loop versioning for LICM
...ferentAliasSet &&
> PtrRtCheck->AliasSetId[i] != PtrRtCheck->AliasSetId[j])
> continue;
>
> By this we allowing RuntimeCheckEmitter as more flexible and providing user
> more control to use it.
>
>
> LoopAccessAnalysis::analyzeLoop
> Here again its very specific to LoopVectorizer.
> The way it handles stores & loads may not be appreciated by other optimization
> expecting other treatment. I suggest we should think on flexibility for user to
> override load & store handling. We can provide virtual methods...
2020 Jul 26
2
[LAA] RtCheck on pointers of different address spaces.
...Evolution*, 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::DominatorTree*...
2020 Jul 26
2
[LAA] RtCheck on pointers of different address spaces.
...Evolution*, 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::DominatorTree*...
2015 Feb 26
1
[LLVMdev] RFC: Loop versioning for LICM
Hi Ashutosh,
Have you been following the recent Loop Access Analysis work? LAA was split out from the Loop Vectorizer that have been performing the kind of loop versioning that you describe. The main reason was to be able to share this functionality with other passes.
Loop Access Analysis is an analysis pass that computes basic memory dependence and the runtime checks. The versioning decision
2015 Feb 26
6
[LLVMdev] RFC: Loop versioning for LICM
I like to propose a new loop multi versioning optimization for LICM.
For now I kept this for LICM only, but it can be used in multiple places.
The main motivation is to allow optimizations stuck because of memory
alias dependencies. Most of the time when alias analysis is unsure about
memory access and it says may-alias. This un surety from alias analysis restrict
some of the memory based