https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #34 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Andreas Krebbel from comment #1) > This appears to be triggered by try_combine unnecessarily setting back the > position by returning the i2 insn. > > When 866 is inserted into 973 866 still needs to be kept around for other > users. So try_combine first merges the two sets into a parallel and > immediately notices that this can't be recognized. Because none of the sets > is a trivial move it is split again into two separate insns. Although the > new i2 pattern exactly matches the input i2 combine considers this to be a > new insn and triggers all the scanning log link creation and eventually > returns it what let's the combine start all over at 866. > > Due to that combine tries many of the substitutions more than 400x. > > Trying 866 -> 973: > 866: r22393:DI=r22391:DI+r22392:DI > 973: r22499:DF=r22498:DF*[r22393:DI] > REG_DEAD r22498:DF > Failed to match this instruction: > (parallel [ > (set (reg:DF 22499) > (mult:DF (reg:DF 22498) > (mem:DF (plus:DI (reg/f:DI 22391 [ _85085 ]) > (reg:DI 22392 [ _85086 ])) [17 *_85087+0 S8 A64]))) > (set (reg/f:DI 22393 [ _85087 ]) > (plus:DI (reg/f:DI 22391 [ _85085 ]) > (reg:DI 22392 [ _85086 ]))) > ]) > Failed to match this instruction: > (parallel [ > (set (reg:DF 22499) > (mult:DF (reg:DF 22498) > (mem:DF (plus:DI (reg/f:DI 22391 [ _85085 ]) > (reg:DI 22392 [ _85086 ])) [17 *_85087+0 S8 A64]))) > (set (reg/f:DI 22393 [ _85087 ]) > (plus:DI (reg/f:DI 22391 [ _85085 ]) > (reg:DI 22392 [ _85086 ]))) > ]) > Successfully matched this instruction: > (set (reg/f:DI 22393 [ _85087 ]) > (plus:DI (reg/f:DI 22391 [ _85085 ]) > (reg:DI 22392 [ _85086 ]))) So this is "unchanged", do we re-combine into it? > Successfully matched this instruction: > (set (reg:DF 22499) > (mult:DF (reg:DF 22498) > (mem:DF (plus:DI (reg/f:DI 22391 [ _85085 ]) > (reg:DI 22392 [ _85086 ])) [17 *_85087+0 S8 A64]))) This one is changed. > allowing combination of insns 866 and 973 > original costs 4 + 4 = 8 > replacement costs 4 + 4 = 8 > modifying insn i2 866: r22393:DI=r22391:DI+r22392:DI > deferring rescan insn with uid = 866. > modifying insn i3 973: r22499:DF=r22498:DF*[r22391:DI+r22392:DI] > REG_DEAD r22498:DF > deferring rescan insn with uid = 973. The change itself looks reasonable given costs, though maybe 2 -> 2 combinations should not trigger when the cost remains the same? In this case it definitely doesn't look profitable, does it? Well, in theory it might hide latency and the 2nd instruction can issue at the same time as the first.
