https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126198
Bug ID: 126198
Summary: [SH] Convert sfuncs to real call insns utilizting
TARGET_INSN_CALLEE_ABI (dbr issue)
Product: gcc
Version: 17.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
On SH, the sfunc patterns that are used to invoke specialized library functions
are treated as instructions instead of being treated as calls. This was done
because there was no way to express different ABIs for different types of call
insns and the sfunc calls all use their own ABI, customized to that particular
operation.
This creates a problem with the delayed-branch pass, which tries to stuff the
delay slots of a call/jump insn. On SH the non-call sfunc insns are marked as
"needs a delay slot" (because they're actually calls/jumps). This seems to hit
some unhandled cases in the dbr pass. As a workaround sh.md adds a
"use_sfunc_addr" insn that is placed right before the actual sfunc insn to
prevent a reordering from happening. If this is not there (or not working
properly, as it happened accidentally during the LRA adaptation), it can ignore
some data dependencies and produce something like ...
correct:
mov.l @115,r2
jsr @r2
< other insn >
incorrect:
jsr @r2
mov.l @r15,r2 // r2 branch target loaded after branch insn fetch
It looks like the newer TARGET_INSN_CALLEE_ABI facility can be used to achieve
the same thing in a cleaner way.
