https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86635
Georg-Johann Lay <gjl at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |wrong-code
--- Comment #2 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
Hi, in expand dump there is
(insn 8 7 9 (parallel [
(set (reg:SF 22 r22)
(mem/u/c:SF (reg/f:PSI 47) [1 a+0 S4 A8 AS7]))
(clobber (reg:SF 22 r22))
(clobber (reg:QI 21 r21))
(clobber (reg:HI 30 r30))
]) "foo.c":4 -1
(nil))
so the problem is that the middle-end provides a hard reg as target that
overlaps one of the interface regs. This reminds me of PR63633 / PR65657.
PR63633 fixed the 3-operand insns case that use hard regs used in the
transparent libgcc calls.
The intention of the clobber of reg 22 (and the other clobbers) is to keep
passes from propagating anything that overlaps the clobbers into an operand of
the insn, xload<mode>_A at that time. The very libcall (xload_<mode>_libgcc)
with its proper operands is generated from that insn during .split1.
FYI, I tried the "proper" solution (use 1-reg constraints etc. and let
reg-alloc do the job) several times and with different versions of gcc, and I
always failed miserably: the code bloat was not acceptable, in particular with
DImode (cf. also PR85805). Lest alone all the spill fails to expect with such
a solution.
Thank you for taking care of this; at the moment all I can do is commenting
from the distance and try to help with analysis and the rationals behind the
current code.
