This bug shows up with diamonds that share unpredicable, unanalyzable branches.
There's an included test case from Hexagon. What was happening was that we were
attempting to predicate the branch instruction despite the fact that it was
checked to be the same. Now for unanalyzable branches we skip over the branch
instructions when predicating the block.
Details
Diff Detail
Event Timeline
lib/CodeGen/IfConversion.cpp | ||
---|---|---|
1815–1820 | No, but we have previously verified that both blocks have the same branch instructions, so we only need one copy. | |
1849 |
No. NumDups2 doesn't count debug values. Would it be clearer if it read (DI2->isBranch() || DI2->isDebugValue())? The goal is to skip all the branch instructions, because they have been checked to match MBB1 and don't need to predicated. |
lib/CodeGen/IfConversion.cpp | ||
---|---|---|
1849 | Ok. Can you add some comments? Can you also add assertion to make sure that the instructions from two blocks are indeed common? |
Added assertion that branches are the same.
Added comments that we have already checked the sameness.
Verified that if I remove the earlier check for branch sameness, the later assertion does fire.
lib/CodeGen/IfConversion.cpp | ||
---|---|---|
797 | I shrank the space here, but don't see a need for a new diff. |
lib/CodeGen/IfConversion.cpp | ||
---|---|---|
1815–1820 | Is it an expectation later that the terminator instruction (in two BBs) are either both removed or they both exist -- i.e. what verifySameInstructions does? You patch looks right, but can you check why the problem does not appear before ? Is it because NumDups2 computation is different? | |
1843 | Why not always skip it? |
Narrowed scope of branch match assertion to the un-analyzable case.
lib/CodeGen/IfConversion.cpp | ||
---|---|---|
1815–1820 | They are expected to match except for a possible unconditional branch, and they may be reversed from each other. It didn't occur because by rescanning, we find new opportunities to if-convert. Previously if the branch instruction were unpredicable, the block was not considered a candidate for diamond if-conversion. Now, as long as the branch instruction at the end of the 2 blocks is the same, we are willing to diamond convert. That means we now miss the case of a "diamond" where both sides end in an unanalyzable but predicable branch. | |
1843 | For analyzable branches, the actual branch instruction may not be necessary. e.g. a diamond, where the join block is either merged, or a fallthrough. In that case, the caller will handle the branch. |
I shrank the space here, but don't see a need for a new diff.