On Tue, 28 Mar 2023, Jakub Jelinek wrote: > On Tue, Mar 28, 2023 at 08:57:12AM +0000, Richard Biener wrote: > > Hmm, but canonicalize_math_p () should be false after vectorization? > > > > When we moved the pass we should have made sure to put the > > PROP_gimple_opt_math property set to pass_expand_powcabs instead. > > Which pass is the one that actually canonicalizes the math such > that we want to keep its choices for later? > I must say I don't know the details why the sincos path has been > even moved.
The pass was split into sincos + pass_expand_powcabs - canonicalization happens through folding and pass_expand_powcabs expands pow (x, 2) to x * x. Folding would make x * x to pow (x, 2) so it's important to set the property after pass_expand_powcabs. I think we moved sincos because vectorizing cexpi never materialized(?) but maybe I misremember. > > Now, the sqrt (sqrt ()) canonicalization to pow (.., 1./4) is > > probably invalid anyway, not sure if we can add a user-written > > vector sqrt testcase that would trigger during the canonicalization > > How do we write user written vector sqrt? I'm not sure ;) > > phase. There are other uses of build_real that have the same > > issue - what's your conclusion this is never a problem there? > > Looking through build_real* calls in match.pd, others are > either on simplifications of some expressions with REAL_CST operand > (so can't be vector then), or using > LOG*/EXP*/CBRT*/SIN*/ATAN*/COS*/POW*/CABS*/HYPOT*/POWI*/SIGNBIT* > calls in the expression being simplified, or this case. > I think no target provides vector optabs for those or they don't > have internal fns at all. > Maybe > (simplify > /* signbit(x) -> x<0 if x doesn't have signed zeros. */ > (SIGNBIT @0) > (if (!HONOR_SIGNED_ZEROS (@0)) > (convert (lt @0 { build_real (TREE_TYPE (@0), dconst0); })))) > ? Maybe. But as said, the fix is probably to move the pass property. Richard.