search for: canfallthrough

...instruction just falls through. I implemented a pass to remove the range check generated before the jump table instruction because it is superfluous. This causes as assertion in MachineBlockPlacement.cpp: assert((!TII->analyzeBranch(*PrevBB, TBB, FBB, Cond) || !PrevBB->canFallThrough()) && "Unexpected block with un-analyzable fallthrough!"); The method MachineBasicBlock::getFallThrough() uses TII->analyzeBranch(). Using analyze branch there doesn't appear to be anyway to signify that a branch is not a simple conditional or a simple indir...

...It's not yet clear to me that the benefit of doing this analysis in the CodeGen layer outweighs the cost and I was trying to clarify what the costs I perceive are. Some basic blocks are glued together and must be placed next to each other. > That situation can be recognized by "MBB->canFallThrough() && > TII->AnalyzeBranch(MBB..)". > > Treat glued-together blocks as super-blocks, and everything should be as > breezy as IR. > But that's just the thing -- a primary goal of this pass would be to *change* the fall-through pattern. Currently, that can be done v...

...Chains.size() != Chains.capacity()) before pushing. + RequiredChain->BBEnd = ++MachineFunction::iterator(From); Does C++ allow this these days? I would prefer llvm::next(MachineFunction::iterator(From)) Note that MachineFunction::iterator decays into an MBB pointer, so you can say FI->canFallThrough() and AnalyzeBranch(*FI...) + WeightedEdge WE = { BaseFrequency * MBPI->getEdgeProbability(From, To), Did we add API for this computation? We intended to add a function that computes this and saturates on overflow etc. > Still, for the test cases that don't tickle the iteration bu...

...itch' terminator (I think), and so the existing MBB placement code just bails on non-branch-exit blocks. Those are all the wrong reasons for not doing the right thing. Some basic blocks are glued together and must be placed next to each other. That situation can be recognized by "MBB->canFallThrough() && TII->AnalyzeBranch(MBB..)". Treat glued-together blocks as super-blocks, and everything should be as breezy as IR. I realize the MBB interface is not the prettiest. Suggestions for cleaning it up are very welcome. /jakob -------------- next part -------------- An HTML attac...

...iately after the block and calling updateTerminator() will give you a fall-through. If AnalyzeBranch() fails, you can still check if the last instruction in the block is an unpredicated barrier. If so, it is still safe to move the successors around, but that block will never be a fall-through. The canFallThrough() function implements this check. If the last instruction in the block is predicated or not a barrier, you must keep it together with its layout successor. This should only happen in rare cases where it is necessary. For example, I am planning to lower invoke instructions into call instructions th...

...lling updateTerminator() will give you a > fall-through. > > If AnalyzeBranch() fails, you can still check if the last instruction in > the block is an unpredicated barrier. If so, it is still safe to move the > successors around, but that block will never be a fall-through. The > canFallThrough() function implements this check. > > If the last instruction in the block is predicated or not a barrier, you > must keep it together with its layout successor. This should only happen in > rare cases where it is necessary. For example, I am planning to lower invoke > instructions i...

On Tue, Oct 18, 2011 at 2:59 PM, Cameron Zwarich <zwarich at apple.com> wrote: > On Oct 18, 2011, at 2:53 AM, Chandler Carruth wrote: > > > Hello, > > > > I'm working on basic-block placement optimizations based on branch > probability information. I've run into a stumbling block though. One of the > existing passes to do this, essentially a dead pass

...; > - Please add a description of the algorithm. > - Please add a comment to the BlockChain class. > - Use a separate anonymous namespace per class, and don't indent for the namespace. > ... > Note that MachineFunction::iterator decays into an MBB pointer, so you can say FI->canFallThrough() and AnalyzeBranch(*FI...) > > + WeightedEdge WE = { BaseFrequency * MBPI->getEdgeProbability(From, To), > > Did we add API for this computation? We intended to add a function that computes this and saturates on overflow etc. Overflow is handled transparently in the overload...

...will give you a >> fall-through. >> >> If AnalyzeBranch() fails, you can still check if the last instruction in >> the block is an unpredicated barrier. If so, it is still safe to move the >> successors around, but that block will never be a fall-through. The >> canFallThrough() function implements this check. >> >> If the last instruction in the block is predicated or not a barrier, you >> must keep it together with its layout successor. This should only happen in >> rare cases where it is necessary. For example, I am planning to lower invoke &gt...

...- Please add a comment to the BlockChain class. > Done. > > - Use a separate anonymous namespace per class, and don't indent for the > namespace. > Done. > > > ... > > Note that MachineFunction::iterator decays into an MBB pointer, so you > can say FI->canFallThrough() and AnalyzeBranch(*FI...) > I'm aware, but there were a few weird places where it didn't happen, and 'From' seemed like a more readable name anyways... Lemme know if you'd really rather I use the iterator everywhere. > > > > + WeightedEdge WE = { BaseFre...