MipsLongBranchPass and MipsHazardSchedule passes are joined to one pass because of mutual conflict.
When MipsHazardSchedule inserts 'nop's, it potentially breaks some jumps, so they have to be expanded
to long branches. When some branch is expanded to long branch, it potentially creates a hazard situation,
which should be fixed by adding nops.
This pass now combine these two passes, and runs them alternately until one of them reports no changes
were made.
Details
- Reviewers
petarj sdardis - Commits
- rGa5f755186a7d: [mips] Merge MipsLongBranch and MipsHazardSchedule passes
rG4977705727ed: [mips] Revert Merge MipsLongBranch and MipsHazardSchedule passes
rGde7be5e46f9e: [mips] Merge MipsLongBranch and MipsHazardSchedule passes
rL332977: [mips] Merge MipsLongBranch and MipsHazardSchedule passes
rL332837: [mips] Revert Merge MipsLongBranch and MipsHazardSchedule passes
rL332834: [mips] Merge MipsLongBranch and MipsHazardSchedule passes
Diff Detail
- Repository
- rL LLVM
Event Timeline
lib/Target/Mips/MipsBranchExpansion.cpp | ||
---|---|---|
789 | I thought one more time about this, and I believe that this loop and it's condition are wrong. We have to repeat these steps until no branches are expanded, as branch expansion can cause another branch to go out of range. With loop like that, this situation is possible:
which may leave some branches broken. |
Comments resolved.
Regarding my inline comment, there is no need to update that, as that case is already covered in handlePossibleLongBranch(...) function in while(...) loop.
Removed unused part of code, related to MBB address calculation.
lib/Target/Mips/MipsBranchExpansion.cpp | ||
---|---|---|
142 | "Mips Branch Expansion Pass" | |
369–372 | These two can be lifted to be private class members, so all functions can access them. | |
709–712 | This hunk should be part of the runOnMachineFunction function, rather than here. | |
lib/Target/Mips/MipsTargetMachine.cpp | ||
297–302 | Rework this comment to explain what the pass does rather than making references to MipsLongBranchPass and MipsHazardSchedule. | |
test/CodeGen/Mips/branch-relaxation-with-hazard.ll | ||
2–3 | Use -mtriple=mips-img-linux-gnu here and use the update_llc_checks.py script on this file. | |
5 | Remove this. |
test/CodeGen/Mips/branch-relaxation-with-hazard.ll | ||
---|---|---|
2–3 | I did as suggested, though I am not sure if this is the expected output. |
LGTM after addressing my comments inline.
lib/Target/Mips/MipsBranchExpansion.cpp | ||
---|---|---|
775 | This isn't clang formatted. | |
test/CodeGen/Mips/branch-relaxation-with-hazard.ll | ||
2–3 | I see that now. It's to do with inline assembly getting wrapped in .set directives that correspond to the assembly that ends a function. You'll have to go back to your handwritten test instead. |
Updated the patch, so that buildbots do not fail.
The problem was in forcing the extension to long branches in every iteration,
which causes infinite loop.
it inserts nops to prevent forbidden slot hazards.