http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50829
Vladimir Makarov <vmakarov at redhat dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |vmakarov at redhat dot com --- Comment #5 from Vladimir Makarov <vmakarov at redhat dot com> 2011-11-24 03:29:09 UTC --- The following code is generated before RA: ... (insn 7 3 11 2 (set (reg:V4DF 63) (unspec:V4DF [ (reg/v:V2DF 62 [ x ]) ] UNSPEC_CAST)) ./include/avxintrin.h:1413 1960 {avx_pd256_pd} (nil)) (insn 11 7 17 2 (set (reg:V4DF 65) (vec_concat:V4DF (vec_select:V2DF (reg:V4DF 63) (parallel [ (const_int 0 [0]) (const_int 1 [0x1]) ])) (reg/v:V2DF 62 [ x ]))) ./include/avxintrin.h:715 1933 {vec_set_hi_v4df} (expr_list:REG_DEAD (reg:V4DF 63) (expr_list:REG_DEAD (reg/v:V2DF 62 [ x ]) (nil)))) ... First of all unspec in insn 7 hides that 63 and 62 has the same value. But even if the unspec were absent, IRA as most other RAs finds conflicts based on live ranges not on the value of in the pseudos. The finding conflicts based on GVN is very expensive and gives nothing on the most code (I did GVN based conflict recognition about 8 years ago, it is described in the 2nd GCC summit proceedings if I remember correctly). As 62 and 63 conflicts they get different hard registers. I guess that the right RTL generation (using one pseudo for 62 and 63) should be done somewhere outside IRA.