[Bug rtl-optimization/56339] [4.8 Regression]: Suboptimal register allocation

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56339

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P2

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-11 11:57:57 UTC ---
I don't think this is P1.
When looking at the dumps, right after expansion the 4.7 expanded code actually
looks much worse compared to the 4.8 expanded one (4.7 goes through memory,
while 4.8 through subregs), in *.ud-dce it is pretty much comparable, though
4.7 has one extra move:
    2 r62:DF=xmm0:DF
      REG_DEAD: xmm0:DF
    6 r64:DF=xmm2:DF
      REG_DEAD: xmm2:DF
   21 r66:DF=r62:DF
      REG_DEAD: r62:DF
    7 NOTE_INSN_FUNCTION_BEG
   10 r65:DF=r64:DF+r66:DF
      REG_DEAD: r66:DF
      REG_DEAD: r64:DF
   15 xmm0:DF=r65:DF
      REG_DEAD: r65:DF
   18 use xmm0:DF
in 4.7 vs.
    2: r64:DF=xmm0:DF
      REG_DEAD xmm0:DF
    8: r66:DF=xmm2:DF
      REG_DEAD xmm2:DF
    9: NOTE_INSN_FUNCTION_BEG
   12: r67:DF=r66:DF+r64:DF
      REG_DEAD r66:DF
      REG_DEAD r64:DF
   17: xmm0:DF=r67:DF
      REG_DEAD r67:DF
   20: use xmm0:DF
in 4.8.  The combiner change is what matters for the later behavior of regmove,
RA and reload/LRA, but unfortunately that is an ICE fix that can't be reverted,
we really must avoid to propagating hard registers too early, otherwise RA
needs to just give up.
So, in 4.7 we end up with r65:DF=xmm2:DF+r62:DF after combine, while 4.8 still
uses pseudos.  Which is the reason why regmove sets that into the optimal for
this testcase r65:DF=xmm2:DF+r65:DF, because it has no other choice (the
operand was already a hard reg), while in 4.8 it has a choice (sees two
different pseudos, and chooses in this case the wrong one).  I'm afraid there
is no easy fix, so IMHO this needs to be postponed for 4.9.