https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107432
--- Comment #7 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to Hongtao.liu from comment #6)
> > Guess expand_vector_conversion can be optimized.
>
> if (INTEGRAL_TYPE_P (TREE_TYPE (ret_type))
> && SCALAR_FLOAT_TYPE_P (TREE_TYPE (arg_type)))
> code = FIX_TRUNC_EXPR;
> else if (INTEGRAL_TYPE_P (TREE_TYPE (arg_type))
> && SCALAR_FLOAT_TYPE_P (TREE_TYPE (ret_type)))
> code = FLOAT_EXPR;
>
> It only supports floatmn2/fix_truncmn2 for float <-> integer.
>
> But we can also supports extendmn2/zero_extendmn2/truncmn2 for float <->
> float, integer <-> integer.
>
> Or are there any concerns and VEC_PACK_TRUNC_EXPR,
> VEC_PACK_FIX_TRUNC_EXPR,VEC_PACK_FLOAT_EXPR are used on purpose?
May be we can add some gimple simplication in match.pd to hanlde
_4 = VEC_PACK_TRUNC_EXPR <a_1(D), { 0, 0, 0, 0 }>;
_5 = BIT_FIELD_REF <_4, 128, 0>;
and
_4 = [vec_unpack_lo_expr] a_1(D);
_5 = [vec_unpack_hi_expr] a_1(D);
_2 = {_4, _5};
Since loop vectorizer may also create vec_unpack_lo_expr/vec_unpack_hi_expr.
