https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68404
--- Comment #25 from Bernd Schmidt <bernds at gcc dot gnu.org> ---
(In reply to Bill Schmidt from comment #9)
> Finally got back to this for a bit. I've tracked the problem down to the
> register renaming pass. I suspect it's having trouble with the
> fusion_gpr_load_di pattern:
>
> (insn 452 236 243 19 (set (reg:DI 9 9)
> (unspec:DI [
> (zero_extend:DI (mem:SI (plus:DI (plus:DI (reg:DI 9 9 [335])
> (const_int 65536 [0x10000]))
> (const_int -21428 [0xffffffffffffac4c])) [160
> MEM[(\
> struct target_reload *)_130 + 44108B]+0 S4 A32]))
> ] UNSPEC_FUSION_GPR))
> /home/wschmidt/gcc/gcc-mainline-test/gcc/call\
> er-save.c:141 757 {fusion_gpr_load_di}
> (nil))
>
> At a guess, the (mem (plus (plus (reg ... pattern might have caught it by
> surprise, making the reference to (reg:DI 9 9) get missed in the analysis.
I looked into the regrename issue. The real problem with the pattern above is
that the output operand is earlyclobber, so the input should not have used r9
as well. I haven't yet investigated how that occurred but I'm willing to bet
that the blame is on the machine description. regrename is definitely fine.
