[Bug rtl-optimization/48037] Missed optimization: unnecessary register moves

["law at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #6 from Jeffrey A. Law <law at redhat dot com> 2011-03-14 15:54:57 UTC ---
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/14/11 09:46, rguenth at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48037
> 
> --- Comment #5 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-03-14 15:45:53 UTC ---
> (In reply to comment #4)
>>> --- Comment #3 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-03-09 12:01:10 UTC ---
>>>> As of the register moves you are seeing, we have the long-time known problem
>>>> that we fail to allocate registers in a way to have the function return
>>>> value in-place.  Maybe we are just confusing IRA with the explicit move
>>>> to that register?
>>>>
>>>> (insn 13 11 18 2 (set (reg:V2DF 72)
>>>>         (vec_concat:V2DF (reg:DF 67)
>>>>             (reg:DF 69))) t.c:8 1557 {*vec_concatv2df}
>>>>      (expr_list:REG_DEAD (reg:DF 69)
>>>>         (expr_list:REG_DEAD (reg:DF 67)
>>>>             (nil))))
>>>>
>>>> (insn 18 13 21 2 (set (reg/i:V2DF 21 xmm0)
>>>>         (reg:V2DF 72)) t.c:10 1127 {*movv2df_internal}
>>>>      (expr_list:REG_DEAD (reg:V2DF 72)
>>>>         (nil)))
>>>>
>>>> why is combine not able to change this to
>>>>
>>>> (insn 13 11 18 2 (set (reg/i:V2DF 21 xmm0)
>>>>         (vec_concat:V2DF (reg:DF 67)
>>>>             (reg:DF 69))) t.c:8 1557 {*vec_concatv2df}
>>>>      (expr_list:REG_DEAD (reg:DF 69)
>>>>         (expr_list:REG_DEAD (reg:DF 67)
>>>>             (nil))))
>>>>
>>>> ? (it doesn't even try this combination)
>>>
>>> Probably because of the check in cant_combine_insn_p (SSE_FIRST_REG is likely
>>> spilled on x86).
>> Right.  I recently looked into a similar problem; ISTM we ought to be
>> able to come up with better rules than never combine if one of the regs
>> is a likely spilled reg.
> 
> True, though relying on the combiner is also somewhat odd.  Why does
> the RA not consider coalescing the return register with a pseudo?
It certainly considers it.  I haven't looked the IRA dumps for this
particular testcase.

In the case I was looking a recently, IRA had two hard reg copies to
consider (one from an arg register and one to the return register), thus
either was considered the same cost.   I'd tried to do some hacks to
combine but didn't get far.   See PR47521.

jeff
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNfjpEAAoJEBRtltQi2kC7GW8IAJtaQozSKemLZo+0W+2Ei90n
81BJbJjuh6ZPyNMrv3XU3xkswlBzwbVN1yIDg4lthZkgSUCsavjZalI63DoOgdNo
N6lQuGvO9/nNLzZB0NbJX5EZivGVJnsZA0CfHJAN1UICXGzA5d4x6cLk3+erDY3E
8qudvAb+hl30yIlGuAulp0KDHCCAYSzEuTRKF+2I+0yNPTn+XsBkk18SuEVoSTad
GVB+mkoGJm97h0kAwdIE7Z0M4P+2EX3L1Ba1i9U13zQIoVYp2TSLnQMNF/gKiQxQ
DKWncl08kIScsRNICNiUcOeo78/8J6fASvHYUf4L9KYdk3OfIknB+6zANR1JKkI=
=t2/L
-----END PGP SIGNATURE-----