[Bug target/103771] [12 Regression] Missed vectorization under -mavx512f -mavx512vl after r12-5489

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103771

--- Comment #30 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 19 Jan 2022, crazylht at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103771
> 
> --- Comment #29 from Hongtao.liu <crazylht at gmail dot com> ---
> (In reply to Richard Biener from comment #28)
> > (In reply to Hongtao.liu from comment #25)
> > > in fold_unary_loc
> > > ---cut from fold-const.cc-----
> > >  9276      else if (TREE_CODE (arg0) == COND_EXPR)
> > >  9277        {
> > >  9278          tree arg01 = TREE_OPERAND (arg0, 1);
> > >  9279          tree arg02 = TREE_OPERAND (arg0, 2);
> > >  9280          if (! VOID_TYPE_P (TREE_TYPE (arg01)))
> > >  9281            arg01 = fold_build1_loc (loc, code, type,
> > >  9282                                 fold_convert_loc (loc,
> > >  9283                                                   TREE_TYPE (op0),
> > > arg01));
> > >  9284          if (! VOID_TYPE_P (TREE_TYPE (arg02)))
> > >  9285            arg02 = fold_build1_loc (loc, code, type,
> > >  9286                                 fold_convert_loc (loc,
> > >  9287                                                   TREE_TYPE (op0),
> > > arg02));
> > >  9288=>        tem = fold_build3_loc (loc, COND_EXPR, type, TREE_OPERAND
> > > (arg0, 0),
> > >  9289                             arg01, arg02);
> > > 
> > > -----------end---------------
> > > 
> > > gcc always tries to simplify (convert (cond (cmp a b) c d) ---- > (cond (cmp
> > > a b) (convert c) (convert d))， exactly the opposite of what this case wants.
> > 
> > It also then undos this if the result didn't simplify and plays trick to
> > avoid
> > recursions.
> > 
> > I think this particular transform ought to be specialized, maybe to
> > (T)p?(T')a:(T')b or maybe done during gimplification or RTL expansion only.
> > 
> > The "cheap" way of avoiding a conflict is to wrap the match.pd pattern
> > with opposite logic in
> > 
> > #if GIMPLE
> > #endif
> > 
> It doesn't work, 
> > (with a comment explaining this)
> > 
> > Note that we can move a conversion out only if the sources of the conversions
> > have compatible types but we always can move a conversion in.
> > 
> > Alternatively this transform can also be done in a vectorizer pattern based
> > on vector compatibility of the ?: predicate with the data.
> yes, I'm thinking of doing this in fold_build_cond_expr which is only used by
> pass_ifcvt to generate cond_expr.

That's also a reasonable place but the vectorizer pattern recog phase
might have more contextual information to determine the best types
to use.   fold_build_cond_expr is probably easiest to adjust though.