https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79593
--- Comment #21 from Jeffrey A. Law <law at redhat dot com> ---
We have this after IRA:
(insn 27 26 28 4 (set (reg:DI 101 [ pretmp_22 ])
(zero_extend:DI (subreg:SI (reg:SF 91 [ pretmp_22 ]) 0))) "j.C":20:35
114 {*zero_extendsidi2}
(expr_list:REG_DEAD (reg:SF 91 [ pretmp_22 ])
(nil)))
(insn 28 27 29 4 (set (reg:XF 100)
(float:XF (reg:DI 101 [ pretmp_22 ]))) "j.C":20:35 169 {floatdixf2}
(expr_list:REG_DEAD (reg:DI 101 [ pretmp_22 ])
(nil)))
Where 91 and 101 will get assigned to memory locations because of the 'm'
constraint for floatdixf2. r100 gets a hard register. We're going to need a
reload for insn 27. So after LRA we have:
(insn 100 26 27 4 (set (reg:SI 0 ax [110])
(mem/c:SI (reg/f:SI 7 sp) [6 %sfp+-8 S4 A64])) "j.C":20:35 67
{*movsi_internal}
(nil))
(insn 27 100 28 4 (set (mem/c:DI (reg/f:SI 7 sp) [6 %sfp+-8 S8 A64])
(zero_extend:DI (reg:SI 0 ax [110]))) "j.C":20:35 114
{*zero_extendsidi2}
(nil))
[ insn 28 doesn't really play a role here other than requiring the 'm'
operand]
The x86 backend has a splitter to optimize insn 27. So post LRA splitting
generates:
(insn 100 26 107 4 (set (reg:SI 0 ax [110])
(mem/c:SI (reg/f:SI 7 sp) [6 %sfp+-8 S4 A64])) "j.C":20:35 67
{*movsi_internal}
(nil))
(insn 107 100 108 4 (set (mem/c:SI (reg/f:SI 7 sp) [6 %sfp+-8 S4 A64])
(reg:SI 0 ax [110])) "j.C":20:35 67 {*movsi_internal}
(nil))
(insn 108 107 28 4 (set (mem/c:SI (plus:SI (reg/f:SI 7 sp)
(const_int 4 [0x4])) [6 %sfp+-4 S4 A32])
(const_int 0 [0])) "j.C":20:35 67 {*movsi_internal}
(nil))
Now we've finally exposed the redundancy. This can be addressed in DSE2
which runs after SPLIT2. But it's not all that generally effective. Figure
we're getting ~8 hits per stage during a bootstrap -- all in the runtime
system.
I looked at perhaps trying to detect the partial dead store in postreload-gcse.
THere's a lot of good memory tracking bits in here, but it's still not a good
fit.
It doesn't really feel like an IRA/LRA problem to me. Their decisions are sane
AFAICT.
We could try and catch it with a new peephole pattern, but that seems even less
desirable than detecting this in a generic way during DSE.
