On Wed, Aug 19, 2015 at 6:53 AM, Hurugalawadi, Naveen <naveen.hurugalaw...@caviumnetworks.com> wrote: > Hi Richard, > > Thanks very much for your review and comments. > >>> Can you point me to which patterns exhibit this behavior? > > root(x)*root(y) as root(x*y) > expN(x)*expN(y) as expN(x+y) > pow(x,y)*pow(x,z) as pow(x,y+z) > x/expN(y) into x*expN(-y) > > Long Double and Float variants FAIL with segmentation fault with these > patterns in match.pd file for AArch64.
Presumably the backend tells GCC the builtins are not available. > However, most of these work as expected with X86_64. > > I had those implemented as per the fold-const.c which can be found at:- > https://gcc.gnu.org/ml/gcc/2015-08/msg00021.html > >>> (mult (SQRT@1 @0) @1) > > Sorry for the typo in there. > However, the current pattern does not generate the optimized pattern as > expected. > x_2 = ABS_EXPR <x_1(D)>; > return x_2; I see. But I can't really help without a testcase that I can use to have a look (same for the above issue with the segfaults). >>> use (rdiv (POW @0 REAL_CST@1) @0) > > It generates ICE with the above modification > internal compiler error: tree check: expected ssa_name, have var_decl in > simplify_builtin_call, at tree-ssa-forwprop.c:1259 Hmm. Indeed, replacing a non-call with a call isn't very well supported yet. A quick "fix" to avoid this ICE would disable the pattern for -ferrno-math. If you open a bugreport with the pattern and a testcase I'm going to have a closer look. > Also, can you please explain me the significance and use of ":s" > I could understand it a bit but still confused about its use in match.pd ":s" is important so that when we have, say tem = pow (x, 4.5); tem2 = tem / x; foo (tem); thus the result of 'pow (x, 4.5)' is used in the pattern we match and also elsewhere, we avoid turning this into tem = pow (x, 4.5); tem2 = pow (x, 3.5); foo (tem); which is of course more expensive than doing the division. Thus it makes sure that parts of the patterns we don't use in the result are later removed as dead. Richard. > Thanks, > Naveen