llvm.org GIT mirror llvm / 45fb79b
Make a somewhat subtle change in the logic of block placement. Sometimes the loop header has a non-loop predecessor which has been pre-fused into its chain due to unanalyzable branches. In this case, rotating the header into the body of the loop in order to place a loop exit at the bottom of the loop is a Very Bad Idea as it makes the loop non-contiguous. I'm working on a good test case for this, but it's a bit annoynig to craft. I should get one shortly, but I'm submitting this now so I can begin the (lengthy) performance analysis process. An initial run of LNT looks really, really good, but there is too much noise there for me to trust it much. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@154395 91177308-0d34-0410-b5e6-96231b3b80d8 Chandler Carruth 8 years ago
1 changed file(s) with 12 addition(s) and 0 deletion(s). Raw diff Collapse all Expand all
546546 MachineBlockPlacement::findBestLoopTop(MachineFunction &F,
547547 MachineLoop &L,
548548 const BlockFilterSet &LoopBlockSet) {
549 // We don't want to layout the loop linearly in all cases. If the loop header
550 // is just a normal basic block in the loop, we want to look for what block
551 // within the loop is the best one to layout at the top. However, if the loop
552 // header has be pre-merged into a chain due to predecessors not having
553 // analyzable branches, *and* the predecessor it is merged with is *not* part
554 // of the loop, rotating the header into the middle of the loop will create
555 // a non-contiguous range of blocks which is Very Bad. So start with the
556 // header and only rotate if safe.
557 BlockChain &HeaderChain = *BlockToChain[L.getHeader()];
558 if (!LoopBlockSet.count(*HeaderChain.begin()))
559 return L.getHeader();
549561 BlockFrequency BestExitEdgeFreq;
550562 MachineBasicBlock *ExitingBB = 0;
551563 MachineBasicBlock *LoopingBB = 0;