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.
