Move some flag_unsafe_math_optimizations using simplify and match

Richard Biener richard.guenther@gmail.com
Wed Aug 19 10:06:00 GMT 2015


On Wed, Aug 19, 2015 at 6:53 AM, Hurugalawadi, Naveen
<Naveen.Hurugalawadi@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



More information about the Gcc-patches mailing list