https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111114
--- Comment #6 from Lehua Ding <lehua.ding at rivai dot ai> ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Lehua Ding from comment #4)
> > Just to double check, are you saying something like the bellow? But I don't
> > feel like the purpose is quite the same though. The match here was supposed
> > to remove the CONVERT operation. Whereas I was hoping to reverse the order
> > in order to combine them.
> >
> > ```
> > (simplify
> > (convert (vec_cond:s @0 @1 @2))
> > (if (VECTOR_TYPE_P (type)
> > && types_match (TREE_TYPE (@0), truth_type_for (type))
> > && (TREE_CODE (@1) == VECTOR_CST || TREE_CODE (@2) == VECTOR_CST))
> > (vec_cond @0 (convert @1) (convert @2))))
> > ```
>
> Before any changes, we currently get:
> vect__5.14_56 = .MASK_LEN_LOAD (vectp_a.12_54, 8B, mask__24.11_52, _67, 0);
> vect_patt_40.15_58 = VEC_COND_EXPR <mask__24.11_52, vect__5.14_56, { 1, 1,
> 1, 1, 1, 1, 1, 1 }>;
> vect_patt_41.16_59 = (vector(8) short unsigned int) vect_patt_40.15_58;
>
> I assumed you want to push that convert to be before the VEC_COND_EXPR,
> correct?
Yes, By this I mean that changing the order does not reduce the instructions,
so it does not feel easy to assess whether it is reasonable or not. Because
vect_recog_over_widening_pattern considers vcond_mask + convert to be more
efficient than convert + vcond_mask. What do you think?
