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.
