Override fixupNeedsRelaxationAdvanced to avoid RISCV MC Branch Relaxation always promote 16-bit branches to 32-bit form when RISCV linker relaxation enabled.
Diff Detail
- Repository
- rL LLVM
Event Timeline
test/MC/RISCV/relocations.s | ||
---|---|---|
93 | Hi Shiva, I noticed that gcc-as will relax jumps to unresolved symbols. only generates rvc-jump for resolved ones.
We can still maintain this behavior by checking the "Fixup" kind and "resolved" in fixupNeedsRelaxationAdvanced. However, this is a better code size optimization I think if the c.jal target appears to be within reach during linking. |
test/MC/RISCV/relocations.s | ||
---|---|---|
93 | It would be great to expand the tests to cover the case of an unresolved jump target. Matching the gcc behaviour seems a sensible starting point. |
test/MC/RISCV/relocations.s | ||
---|---|---|
93 | Hi @sabuasal. Resolved will always false when -mrelax enabled due to shouldForceRelocation. If we relax c.jal by checking "Fixup" and "Resolved", c.jal will always relax to jal when -mrelax enabled even if the symbol actually could be resolved. |
test/MC/RISCV/relocations.s | ||
---|---|---|
93 | Hi Shiva, if (STI.getFeatureBits()[RISCV::FeatureRelax]) is false we know that Resolved is false because the symbol is actually unresolved, not that it was set to false due to shouldForceRelection() behaviour. If that applies and the FixUp kind you get belongs to a compression fixup then we should just relax the instruction. This way we can match gcc for compressed jumps to unresolved symbols. What do you think? | |
93 | If after that you think the code will be too ugly I an fine going back to your original patch. |
test/MC/RISCV/relocations.s | ||
---|---|---|
93 | Hi @sabuasal, bool fixupNeedsRelaxationAdvanced(const MCFixup &Fixup, bool Resolved, uint64_t Value, const MCRelaxableFragment *DF, const MCAsmLayout &Layout) const override { if (!STI.getFeatureBits()[RISCV::FeatureRelax] && !Resolved) return true; return fixupNeedsRelaxation(Fixup, Value, DF, Layout); } Yes, we could match gcc behaviour for unresolved symbols when relaxation disabled, but c.jal still not relax to jal for unresolved symbols when relaxation enabled. |
test/MC/RISCV/relocations.s | ||
---|---|---|
93 | bool fixupNeedsRelaxationAdvanced(const MCFixup &Fixup, bool Resolved, uint64_t Value, const MCRelaxableFragment *DF, const MCAsmLayout &Layout) const override { if (!STI.getFeatureBits()[RISCV::FeatureRelax] && !Resolved) return true; if (STI.getFeatureBits()[RISCV::FeatureRelax]) return true; return fixupNeedsRelaxation(Fixup, Value, DF, Layout); } |
test/MC/RISCV/relocations.s | ||
---|---|---|
93 | Oops, please ignore the above comment I hit submit without realizing it. |
test/MC/RISCV/relocations.s | ||
---|---|---|
93 |
Yea I believe that is true and it make sense to me.
I just took a look at the assembler framework again. The problem is that the relaxation logic, which happens during the layoutOnce() shares some logic with the Relocation recording by calling evaluateFixup which checks shouldForceRelocation in the backend. The only way I can see this working is if the fixupNeedsRelocationAdvnced() duplicates the work in evaluateFixup() to get the "Value" and "IsResolved". This way we can separate the relocation and relaxation logic but that does sound too invasive. I think you are right, I might heave lead you in the wrong way, lets o back to the old patch. |
test/MC/RISCV/relocations.s | ||
---|---|---|
93 | Hi Sabuasal. Utilizing existing target hook always better than introducing a new one. Your comment's lead us to explore the possibility and make the new target hook more reasonable. Thanks for your comments and let's push the old one. |
Hi Shiva,
I noticed that gcc-as will relax jumps to unresolved symbols. only generates rvc-jump for resolved ones.
We can still maintain this behavior by checking the "Fixup" kind and "resolved" in fixupNeedsRelaxationAdvanced. However, this is a better code size optimization I think if the c.jal target appears to be within reach during linking.
@asb
What do you think?