This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: fast-math optimization question
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Steve Ellcey <sellcey at mips dot com>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, Andrew Pinski <pinskia at gmail dot com>, GCC Mailing List <gcc at gcc dot gnu dot org>, Richard Biener <richard dot guenther at gmail dot com>
- Date: Fri, 10 Oct 2014 11:07:52 +0200
- Subject: Re: fast-math optimization question
- Authentication-results: sourceware.org; auth=none
- References: <10940e4b-0c5c-4a2a-9432-6385e9590fb4 at BAMAIL02 dot ba dot imgtec dot org> <CA+=Sn1mkOCmPxPmn-RYkE+CJBrQ=8U7O07RUj8wwc6KyuXzrJQ at mail dot gmail dot com> <1412879523 dot 28410 dot 133 dot camel at ubuntu-sellcey> <Pine dot LNX dot 4 dot 64 dot 1410091947001 dot 14581 at digraph dot polyomino dot org dot uk> <1412895334 dot 28410 dot 143 dot camel at ubuntu-sellcey>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Thu, Oct 09, 2014 at 03:55:34PM -0700, Steve Ellcey wrote:
> On Thu, 2014-10-09 at 19:50 +0000, Joseph S. Myers wrote:
> > On Thu, 9 Oct 2014, Steve Ellcey wrote:
> >
> > > Do you know which pass does the simple
> > > '(float)function((double)float_val)' demotion? Maybe that would be a
> > > good place to extend things.
> >
> > convert.c does such transformations. Maybe the transformations in there
> > could move to the match-and-simplify infrastructure - convert.c is not a
> > particularly good place for optimization, and having similar
> > transformations scattered around (fold-const, convert.c, front ends, SSA
> > optimizers) isn't helpful; hopefully match-and-simplify will allow some
> > unification of this sort of optimization.
>
> I did a quick and dirty experiment with the match-and-simplify branch
> just to get an idea of what it might be like. The branch built for MIPS
> right out of the box so that was great and I added a couple of rules
> (see below) just to see if it would trigger the optimization I wanted
> and it did. I was impressed with the match-and-simplify infrastructure,
> it seemed to work quite well. Will this branch be included in GCC 5.0?
Though, is such optimization desirable even for fast-math?
I mean, in the normal demotion, all that changes compared to original
source is the possibility of double rounding, or, if right now as in glibc
the *f suffixed varaints aren't 0.5ulp precise while double ones are.
If you want to demote a chain of calls, you add roundings in the middle too,
and depending on which function it is and which exact argument, I'd worry
the maximum error would already be not just slightly higher, but significantly
worse. Even for -ffast-math we want only slightly worse precision, not
significantly worse one.
Jakub