search for: getloopdepth

...sed to index a direction vector. IMHO it would be more clear in general, not only in the context of my project. Off course, it's only a cosmetic proposition and I'm not going to insist on that change. Currently, there are 2 methods to determine the depth of something: a) unsigned LoopInfo::getLoopDepth(BlockT *BB); // Return the loop nesting level of the specified block. b) unsigned Loop::getLoopDepth() // Return the nesting level of this loop. The reason why numbering in b) starts from 1 is to be consistent with numbering in a) (which starts from 0) --- the depth of BB is the same as the...

...void getLoopInfo(const Function& F) const { const LoopInfo *LI = &getAnalysis<LoopInfo> (); Function::const_iterator BB = F.begin(), E = F.end(); for (; BB != E; ++BB) errs() << BB->getName() << " " << LI->getLoopDepth(&*BB) << "\n"; }; virtual bool runOnModule(Module &M) { Module::const_iterator f_it = M.begin(), f_ite = M.end(); for ( ; f_it != f_ite; ++f_it ) { errs() << f_it->getName() << '\n'; if (!f_it->isDeclar...

...BlockIDs()); + MachineBlockFrequencyInfo &MBFI = getAnalysis<MachineBlockFrequencyInfo>(); for (MachineFunction::iterator I = mf.begin(), E = mf.end(); I != E; ++I) { - float Freq = LiveIntervals::getSpillWeight(true, false, - loops->getLoopDepth(I)); + float Freq = + LiveIntervals::getSpillWeight(true, false, MBFI.getBlockFreq(I)); unsigned Num = I->getNumber(); BlockFrequency[Num] = Freq; I think you should leave LiveIntervals out of this and just the block frequency directly, scaled as above. The getSpillWeight()...

...pInfo> (F); please have a look at the declaration of getAnalysis for detail information. best regards ether >        Function::const_iterator BB = F.begin(), E = F.end(); >        for (; BB != E; ++BB) >          errs() << BB->getName() << " " << LI->getLoopDepth(&*BB) << "\n"; >    }; > >    virtual bool runOnModule(Module &M) { >      Module::const_iterator f_it = M.begin(), f_ite = M.end(); >      for ( ; f_it != f_ite; ++f_it ) >      { >        errs() << f_it->getName() << '\n'; >  ...

On 17.06.2013, at 15:56, Diego Novillo <dnovillo at google.com> wrote: > On 2013-06-15 16:39 , Benjamin Kramer wrote: >> Do you want to take over this effort or should I poke more at it? > > Since you've already started, it's easier if you poke more at it. Thanks. I've got a whole bunch of other things to go through. OK, will do. Jakob any comments on the

...Later in the ScopInfo pass it crashes analyzing the SCEV of the > comparison expression (in buildConditionSets ) . It's like if it > recognizes that "i" is a recurring expression that depends on the > execution of a loop, but can't derive that loop, and segfaults in > getLoopDepth ... > > Seems like a bug of the SCEV engine to me., but I'm not sure :( Hi Marcello, sorry for taking so long to reply. I just had a look at your test case and found the problem. What happens is that Polly fails to accept the outer loop (an unrelated issue), such that only the inner loo...

....dylib 0x0000000103fabf79 _ZL13SignalHandleri + 361 2 libsystem_c.dylib 0x00007fff94c8acfa _sigtramp + 26 3 libLLVM-3.1svn.dylib 0x0000000103526810 llvm::SmallVectorTemplateCommon<llvm::SCEV const*>::operator[](unsigned int) + 128 4 LLVMPolly.dylib 0x0000000106867af8 SCEVAffinator::getLoopDepth(llvm::Loop const*) + 72 5 LLVMPolly.dylib 0x00000001068676c7 SCEVAffinator::visitAddRecExpr(llvm::SCEVAddRecExpr const*) + 247 6 LLVMPolly.dylib 0x000000010686710b llvm::SCEVVisitor<SCEVAffinator, isl_pw_aff*>::visit(llvm::SCEV const*) + 283 7 LLVMPolly.dylib 0x0000000106866...

Perfect, thank you very much :) 2011/10/26 Tobias Grosser <tobias at grosser.es>: > On 10/24/2011 11:32 PM, Marcello Maggioni wrote: >> >> Strange , with --enable-shared (I use auto tool by the way ...) it gives: >> >> MacBook-Pro-di-Marcello:examples Kariddi$ ./compile_ex.sh >> not_so_simple_loop >> clang (LLVM option parsing): Unknown command line

...SCEV results valid. Later in the ScopInfo pass it crashes analyzing the SCEV of the comparison expression (in buildConditionSets ) . It's like if it recognizes that "i" is a recurring expression that depends on the execution of a loop, but can't derive that loop, and segfaults in getLoopDepth ... Seems like a bug of the SCEV engine to me., but I'm not sure :( 2011/11/1 Marcello Maggioni <hayarms at gmail.com>: > Mmm, this code seems to kill polly: > > #include <stdio.h> > #include <stdlib.h> > > int main() > { >        char *B; >      ...

...MachineBlockFrequencyInfo &MBFI = getAnalysis<MachineBlockFrequencyInfo>(); > for (MachineFunction::iterator I = mf.begin(), E = mf.end(); I != E; ++I) { > - float Freq = LiveIntervals::getSpillWeight(true, false, > - loops->getLoopDepth(I)); > + float Freq = > + LiveIntervals::getSpillWeight(true, false, MBFI.getBlockFreq(I)); > unsigned Num = I->getNumber(); > BlockFrequency[Num] = Freq; > > I think you should leave LiveIntervals out of this and just the block frequency directly, scaled as...

On 01/08/10 14:20, ether wrote: > sorry that i forgot to change the subjuect Hi ether, sounds interesting. Actually is/may be some kind of region. If you want you can have a look at the analysis, that I wrote. It is not yet finished, not completely documented and work in progress. However the first big comment might be interesting for you. Or seeing the results of opt -regions -analyze

...rashes analyzing the SCEV of the >>> comparison expression (in buildConditionSets ) . It's like if it >>> recognizes that "i" is a recurring expression that depends on the >>> execution of a loop, but can't derive that loop, and segfaults in >>> getLoopDepth ... >>> >>> Seems like a bug of the SCEV engine to me., but I'm not sure :( >> >> Hi Marcello, >> >> sorry for taking so long to reply. I just had a look at your test case >> and found the problem. What happens is that Polly fails to accept the &g...