On February 10, 2018 3:26:46 PM GMT+01:00, Jakub Jelinek <ja...@redhat.com> wrote: >On Sat, Feb 10, 2018 at 12:29:42PM +0100, Richard Biener wrote: >> On February 10, 2018 10:44:37 AM GMT+01:00, Jakub Jelinek ><ja...@redhat.com> wrote: >> >On Sat, Feb 10, 2018 at 08:00:04AM +0100, Richard Biener wrote: >> >> On February 10, 2018 12:37:38 AM GMT+01:00, Jakub Jelinek >> ><ja...@redhat.com> wrote: >> >> >Hi! >> >> > >> >> >Apparently the new pow(C,x) -> exp(log(C)*x) if C > 0 >optimization >> >> >breaks some package (Marek should know which), as it has 7ulp >error. >> >> >Generally one should be prepared for some errors with >-ffast-math. >> >> > >> >> >Though, in this case, if the target has c99 runtime and C is >> >> >a positive 0x1pNN it seems much better to use exp2 over exp, for >> >> >C being 2 pow (2, x) is optimized into exp2 (x) and even for >other >> >> >values log2(C) will still be some positive or negative integer, >so >> >> >in many cases there won't be any rounding errors in the >> >multiplication. >> >> > >> >> >Bootstrapped/regtested on x86_64-linux and i686-linux, ok for >trunk? >> >> >> >> OK. I wonder whether there are vectorized variants in libmvec? >> > >> >Unfortunately libmvec only provides pow and exp, not exp2 nor exp10. >> >> So maybe delay this folding then, there's already two phases we do >for >> math functions. Not sure if they conveniently align with >vectorization... > >How would that delay look like? >If use_exp2 is true and (cfun->curr_properties & PROP_gimple_lvec) == >0, >don't fold it?
I think we have a canonicalize_math phase and an optimization one. But I'm not sure this transform matches either case. Then I guess if we vectorize or slp vectorize the pow >as vector pow, we'd need to match.pd it into the exp (log (vec_cst) * >x). Yes. Of course extending libmvec would be much preferred... Richard. > > Jakub
