https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115264

Jeffrey A. Law <law at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2026-01-09

--- Comment #1 from Jeffrey A. Law <law at gcc dot gnu.org> ---
The two epilogues are because one sets a return value to zero, the other gets
its return value from __strdup.    It's of marginal value, but probably not
terribly bad either.

The more interesting question is the dance with s0.   We have this coming out
of reload (where a0 after insn 14 is used as an argument to a function call). 
So at this point s0 appears used and we're going to need to save/restore it in
the prologue/epilogue.



(insn 9 52 14 2 (set (reg:DI 8 s0 [139])
        (reg/f:DI 2 sp)) "j.c":13:7 275 {*movdi_64bit}
     (expr_list:REG_EQUIV (plus:DI (reg/f:DI 65 frame)
            (const_int -4096 [0xfffffffffffff000]))
        (nil)))
(insn 14 9 10 2 (set (reg:DI 10 a0)
        (reg:DI 8 s0 [139])) "j.c":13:7 275 {*movdi_64bit}
     (expr_list:REG_EQUAL (plus:DI (reg/f:DI 65 frame)
            (const_int -4096 [0xfffffffffffff000]))
        (nil)))

One could legitimately ask why wasn't insn 14 simplified.  That would solve
this problem.

Anyway, fast forward to prologue/epilogue generation and we have:

insn 14: replaced reg 8 with 2 
[ ... ]

(insn 14 52 10 2 (set (reg:DI 10 a0)                                           
                                                (reg/f:DI 2 sp)) "j.c":13:7 275
{*movdi_64bit}                                                                 
     (expr_list:REG_EQUAL (plus:DI (reg/f:DI 65 frame)                         
                                                    (const_int -4096
[0xfffffffffffff000]))                                                         
                   (nil)))                         

That was the last use of s0, but prologue/epilogue generation doesn't know that
and thus it emits the save/restore.

We don't simplify things earlier because the value fp-4096 is needed across the
call.  So we keep it in a register.  It would probably be better to
rematerialize that value.  Rematerialization of the value is the same cost as
the register->register copy (and in this case would remove the use of s0 and
thus is beneficial).

THere's probably something cost-wise we need to fix prior to IRA, or perhaps
more aggressive rematerialization in IRA/LRA.

Reply via email to