https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118012
--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> --- I think Georg-Johann is right that the patterns were introduced for optimization and not canonicalization. Yes, every pattern is also canonicalization, but the patterns transforming COND_EXPRs to straight-line code almost exclusively rely on the full expression being either visible in GENERIC already or for phiopt helping. For those involving operations where no generic inline expansion fallback is present (or where it might be more expensive), a simple way would be to avoid generating > word_mode operations that could be "expensive" (Georg-Johann mentioned multiplication, but also negation might be a candidiate - bit operations might be fine). On RTL we do target costing for if-conversion sequences, PHI-OPT doesn't reject any simplified sequence late - but we're also lacking an easy way to cost "before" vs. "after" (genmatch does not get you a set of all stmts involved in the "before" match, and the "after" result might contain references into the "before" sequence). It might be sensible to have a target hook for GIMPLE if-conversion we could involve for rejecting the replacement sequence, or alternatively a hook that tells us "operation expensive" from a tree-code and mode combination? I could imagine some cases involving __int128_t might be worse on x86-64 as well. Note this wouldn't fix the patterns triggering on GENERIC, and I'd not invoke the hook from the pattern itself. For specific cases improving RTL expansion is also possible - the argument would be that of course the user might have written the "bad" code in the first place and if more profitable, a branchy form should be used for code generation.
