forked from OSchip/llvm-project
Remove an over zealous assert. The assert was trying to catch places
where a chain outside of the loop block-set ended up in the worklist for scheduling as part of the contiguous loop. However, asserting the first block in the chain is in the loop-set isn't a valid check -- we may be forced to drag a chain into the worklist due to one block in the chain being part of the loop even though the first block is *not* in the loop. This occurs when we have been forced to form a chain early due to un-analyzable branches. No test case here as I have no idea how to even begin reducing one, and it will be hopelessly fragile. We have to somehow end up with a loop header of an inner loop which is a successor of a basic block with an unanalyzable pair of branch instructions. Ow. Self-host triggers it so it is unlikely it will regress. This at least gets block placement back to passing selfhost and the test suite. There are still a lot of slowdown that I don't like coming out of block placement, although there are now also a lot of speedups. =[ I'm seeing swings in both directions up to 10%. I'm going to try to find time to dig into this and see if we can turn this on for 3.1 as it does a really good job of cleaning up after some loops that degraded with the inliner changes. llvm-svn: 154287
This commit is contained in:
parent
49158908dc
commit
bed1abf9ca
|
@ -438,7 +438,6 @@ MachineBasicBlock *MachineBlockPlacement::selectBestCandidateBlock(
|
|||
for (SmallVectorImpl<MachineBasicBlock *>::iterator WBI = WorkList.begin(),
|
||||
WBE = WorkList.end();
|
||||
WBI != WBE; ++WBI) {
|
||||
assert(!BlockFilter || BlockFilter->count(*WBI));
|
||||
BlockChain &SuccChain = *BlockToChain[*WBI];
|
||||
if (&SuccChain == &Chain) {
|
||||
DEBUG(dbgs() << " " << getBlockName(*WBI)
|
||||
|
|
Loading…
Reference in New Issue