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?