https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67945
--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to rsand...@gcc.gnu.org from comment #8) > Actually, the problem seems to be that we're oscillating > between forms. > > The old fold-const.c folders converted sequences of sqrts > and cbrts into a pow call while tree-ssa-math-opts.c goes > the other way. In that situation things were well-controlled: > we did both transformations only once, in that order. > Moving the fold-const.c folders to match.pd means that we > try them many times and that ultimately they win. Ah, I was worried about such cases. The fold-const.c/builtins.c code has two kinds of transforms - canonicalizations (producing for example pow (x, 2) from x*x or like in this case pow from sqrt*cbrt) and "simplifications" (well, transforms to "faster" implementations). The canonicalizations are purely to catch more CSE and simplifications. I wonder if we should have two "phases" of simplifications, first aggressively canonicalize and later apply the optimizations. We could key this on a new GIMPLE state, PROP_gimple_XXX (can't figure out a good acronym) and key patterns with it (like we have reload_completed on RTL). The pass deciding it's time to "lower" stuff (rather than canonicalize) would be cse_sincos (the pass doing the transform required for the testcase). Note that some patters in that pass might be moved to match.pd instead so we can key PROP_gimple_XXX on the forwprop pass preceeding cse_sincos (so we can transform all stmts at once).
