On Fri, Aug 28, 2015 at 7:33 AM, Marc Glisse <marc.gli...@inria.fr> wrote: > On Thu, 27 Aug 2015, Andreas Schwab wrote: > >> "Hurugalawadi, Naveen" <naveen.hurugalaw...@caviumnetworks.com> writes: >> >>> * fold-const.c (fold_binary_loc) : Move Optimize >>> root(x)*root(y) as root(x*y) to match.pd. >>> Move Optimize expN(x)*expN(y) as expN(x+y) to match.pd. >>> Move Optimize pow(x,y)*pow(x,z) as pow(x,y+z) to match.pd. >>> Move Optimize a/root(b/c) into a*root(c/b) to match.pd. >>> Move Optimize x/expN(y) into x*expN(-y) to match.pd. >>> >>> * match.pd (mult (root:s @0) (root:s @1)): New simplifier. >>> (mult (POW:s @0 @1) (POW:s @0 @2)) : New simplifier. >>> (mult (exps:s @0) (exps:s @1)) : New simplifier. >>> (rdiv @0 (root:s (rdiv:s @1 @2))) : New simplifier. >>> (rdiv @0 (exps:s @1)) : New simplifier. >> >> >> FAIL: gcc.dg/builtins-11.c (test for excess errors) >> Excess errors: >> builtins-11.c:(.text+0x52): undefined reference to `link_error' > > > Indeed, generic-match ends up testing for sqrt(x)*sqrt(y) before testing for > sqrt(x)@1*@1, so it simplifies it to sqrt(x*x)->abs(x) instead of plain x. > Changing the genmatch machinery to better respect the order of patterns in > match.pd might not be trivial without sacrificing performance, a workaround > might be to add a special pattern sqrt(x)*sqrt(x), or to disable some > patterns for GENERIC so CSE has a chance to run first.
Hum, it _does_ respect ordering (well, it is supposed to). But indeed I can see it does not. Bah. Mind opening a bugreport for this? Thanks, Richard. > -- > Marc Glisse
