search for: getblocknumbered

...rapping) + return true; Why not just return inside if (allCSRUsesInEntryBlock)? 10. +bool PEI::calculateUsedAnticAvail(MachineFunction &Fn) { ... + // Calculate AnticIn, AnticOut using post-order traversal of MCFG. + for (po_iterator<MachineBasicBlock*> + MBBI = po_begin(Fn.getBlockNumbered(0)), + MBBE = po_end(Fn.getBlockNumbered(0)); MBBI != MBBE; ++MBBI) { + MachineBasicBlock* MBB = *MBBI; ... + // Calculate Avail{In,Out} via top-down walk of Machine dominator tree. + for (df_iterator<MachineDomTreeNode*> DI = df_begin(DT.getRootNode ()), + E = df_end(...

Here is an updated patch for shrink wrapping with: - spills/restores done with stack slot stores/loads - stack adjustment removed - refactoring (but still in need of more) - spill/restore insertion code unified with spill/restore placement code Documentation available here<http://wiki.github.com/jdmdj/llvm-work/shrink-wrapping-work> illustrates shrink wrapping with loops and discusses a

On Mon, Mar 2, 2009 at 10:35 AM, Evan Cheng <echeng at apple.com> wrote: > > On Mar 1, 2009, at 2:57 PM, John Mosby wrote: > > Obviously, all of this applies only when spills are done with push/pop, > which is the case on x86. I used this issue to start looking at generalizing > how spills and restores are handled, before looking too closely at other > targets, and

...simplified that before cutting the patch. > 10. > +bool PEI::calculateUsedAnticAvail(MachineFunction &Fn) { > ... > + // Calculate AnticIn, AnticOut using post-order traversal of MCFG. > + for (po_iterator<MachineBasicBlock*> > > > + MBBI = po_begin(Fn.getBlockNumbered(0)), > > > + MBBE = po_end(Fn.getBlockNumbered(0)); MBBI != MBBE; ++MBBI) { > > > + MachineBasicBlock* MBB = *MBBI; > ... > + // Calculate Avail{In,Out} via top-down walk of Machine dominator tree. > > > + for (df_iterator<MachineDomTreeNode*> DI...

...in between. bool runOnMachineFunction(MachineFunction &mf) { BitVector seen( mf.size() ); for( unsigned i = 0, e = mf.size(); i != e; ++i ) { if( seen[i] ) continue; seen[i] = true; MachineBasicBlock * start, *block; start = block = mf.getBlockNumbered(i); std::vector< MachineBasicBlock* > blocks; while( block->succ_size() == 1 && (*block->succ_begin())->pred_size() == 1 ) { block = *block->succ_begin(); seen[block->getNumber()] = true; blocks.push_back( block ); }...

...gt; >> >> 10. >> +bool PEI::calculateUsedAnticAvail(MachineFunction &Fn) { >> ... >> +  // Calculate AnticIn, AnticOut using post-order traversal of MCFG. >> +  for (po_iterator<MachineBasicBlock*> >> >> >> +         MBBI = po_begin(Fn.getBlockNumbered(0)), >> >> >> +         MBBE = po_end(Fn.getBlockNumbered(0)); MBBI != MBBE; ++MBBI) { >> >> >> +    MachineBasicBlock* MBB = *MBBI; >> ... >> +  // Calculate Avail{In,Out} via top-down walk of Machine dominator tree. >> >> >> +  for...

Has anyone written a pass at the MachineFunction level which combines machine basic blocks which is guaranteed to be the single predecessor to another block? Or is there a reason not to combine them? - Thanks Jeff Kunkel

On Oct 6, 2010, at 4:31 PM, Jeff Kunkel wrote: > Has anyone written a pass at the MachineFunction level which combines > machine basic blocks which is guaranteed to be the single predecessor > to another block? Or is there a reason not to combine them? I'm not sure exactly what transformation you're referring to, but BranchFolder::OptimizeBranches does a lot of things like that.

...size() ); >>>>      for( unsigned i = 0, e = mf.size(); i != e; ++i ) { >>>>        if( seen[i] ) >>>>          continue; >>>>        seen[i] = true; >>>>        MachineBasicBlock * start, *block; >>>>        start = block = mf.getBlockNumbered(i); >>>>        std::vector< MachineBasicBlock* > blocks; >>>>        while( block->succ_size() == 1 && >>>> (*block->succ_begin())->pred_size() == 1 ) { >>>>          block = *block->succ_begin(); >>>>          s...

On Thu, 17 Aug 2006, Anton Vayvod wrote: > Thanks, Ralph, this line worked well :) > Here it is, my first patch to LLVM :) > I've changed all allocation_order_begin() and allocation_order_end() methods > to take const MachineFunction &MF as a parameter. I also added const version > of MachineFunction::getInfo<Ty>() method. And I changed three static hasFP() >

...val_Fer::runOnMachineFunction (MachineFunction & mf) { std::vector<MachineBasicBlock *> src_blocks; std::vector<MachineBasicBlock *> dst_blocks; // first, only find the critical edges: for(unsigned u = 0; u < mf.size(); u++) { MachineBasicBlock * mbb = mf.getBlockNumbered(u); for(MachineBasicBlock::succ_iterator succ = mbb->succ_begin(); succ != mbb->succ_end(); succ++) { MachineBasicBlock * mbb_succ = *succ; if(is_critical_edge(*mbb, *mbb_succ)) { src_blocks.push_back(mbb);...

On Tue, 4 Jul 2006, Fernando Magno Quintao Pereira wrote: > However, it does not remove all the critical edges. I am getting a very > weird dataflow graph (even without the Break Critical edges pass). The > dataflow generated by MachineFunction::dump() for the program below is > given here: > http://compilers.cs.ucla.edu/fernando/projects/soc/images/loop_no_crit2.pdf ... > The

...-----------------===// bool CriticalEdgeRemoval_Fer::runOnMachineFunction(MachineFunction & mf) { std::vector<MachineBasicBlock *> src_blocks; std::vector<MachineBasicBlock *> dst_blocks; for(unsigned u = 0; u < mf.size(); u++) { MachineBasicBlock * mbb = mf.getBlockNumbered(u); for(MachineBasicBlock::succ_iterator succ = mbb->succ_begin(); succ != mbb->succ_end(); succ++) { MachineBasicBlock * mbb_succ = *succ; // necessary and sufficient condition that characterizes a critical...