https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94864
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Last reconfirmed| |2020-04-30
Component|target |rtl-optimization
CC| |rguenth at gcc dot gnu.org,
| |segher at gcc dot gnu.org,
| |uros at gcc dot gnu.org
Status|UNCONFIRMED |NEW
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
We're feeding combine with
(insn 7 4 9 2 (set (reg:DF 87)
(vec_select:DF (reg:V2DF 90)
(parallel [
(const_int 1 [0x1])
]))) "y.c":6:26 3195 {sse2_storehpd}
(expr_list:REG_DEAD (reg:V2DF 90)
(nil)))
(insn 9 7 14 2 (set (reg:V2DF 88 [ result ])
(vec_merge:V2DF (vec_duplicate:V2DF (reg:DF 87))
(reg:V2DF 89)
(const_int 1 [0x1]))) "y.c":6:21 2918 {vec_setv2df_0}
(expr_list:REG_DEAD (reg:V2DF 89)
(expr_list:REG_DEAD (reg:DF 87)
(nil))))
which makes
(set (reg:V2DF 88 [ result ])
(vec_merge:V2DF (vec_duplicate:V2DF (vec_select:DF (reg:V2DF 90)
(parallel [
(const_int 1 [0x1])
])))
(reg:V2DF 89)
(const_int 1 [0x1])))
out of this which does not match anything because x86 chooses to use
vec_merge in some and vec_select/vec_concat in other patterns:
(define_insn "*vec_interleave_highv2df"
[(set (match_operand:V2DF 0 "nonimmediate_operand" "=x,v,v,x,v,m")
(vec_select:V2DF
(vec_concat:V4DF
(match_operand:V2DF 1 "nonimmediate_operand" " 0,v,o,o,o,v")
(match_operand:V2DF 2 "nonimmediate_operand" " x,v,1,0,v,0"))
(parallel [(const_int 1)
(const_int 3)])))]
"TARGET_SSE2 && ix86_vec_interleave_v2df_operator_ok (operands, 1)"
"@
unpckhpd\t{%2, %0|%0, %2}
not sure if combine should try to exchange vec_merge for vec_select/vec_concat
or if this is simply the backends fault (or GCCs for even having two ways
to express the same thing...)
