This is the mail archive of the
`gcc@gcc.gnu.org`
mailing list for the GCC project.

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |

Other format: | [Raw text] |

*From*: Richard Biener <richard dot guenther at gmail 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>*Date*: Fri, 10 Oct 2014 09:59:59 +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>

On Fri, Oct 10, 2014 at 12:55 AM, Steve Ellcey <sellcey@mips.com> 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? Yes, I'm working towards merging it piecewise this stage1. > Steve Ellcey > sellcey@mips.com > > > Code added to match-builtin.pd: > > > (if (flag_unsafe_math_optimizations) > /* Optimize "(float) expN(x)" [where x is type double] to > "expNf((float) x)", i.e. call the 'f' single precision func */ > (simplify > (convert (BUILT_IN_LOG @0)) > (if ((TYPE_MODE (type) == SFmode) && (TYPE_MODE (TREE_TYPE (@0)) == DFmode)) > (BUILT_IN_LOGF (convert @0)))) > ) > > (if (flag_unsafe_math_optimizations) > /* Optimize "(float) expN(x)" [where x is type double] to > "expNf((float) x)", i.e. call the 'f' single precision func */ > (simplify > (convert (BUILT_IN_SIN @0)) > (if ((TYPE_MODE (type) == SFmode) && (TYPE_MODE (TREE_TYPE (@0)) == DFmode)) > (BUILT_IN_SINF (convert @0)))) > ) Even better: (if (flag_unsafe_math_optimizations) (for fn (BUILT_IN_LOG BUILT_IN_SIN) ffn (BUILT_IN_LOGF BUILT_IN_SINF) (simplify (convert (fn @0)) (if ((TYPE_MODE (type) == SFmode) && (TYPE_MODE (TREE_TYPE (@0)) == DFmode)) (ffn (convert @0)))))) by means of recursion this will pick up (float)log(sin((double)x)) but also (float)log(sin(x)) if x is double which may be undesired. To avoid that make it match (convert (fn (convert @0))) instead. Richard. > >

**References**:**fast-math optimization question***From:*Steve Ellcey

**Re: fast-math optimization question***From:*Andrew Pinski

**Re: fast-math optimization question***From:*Steve Ellcey

**Re: fast-math optimization question***From:*Joseph S. Myers

**Re: fast-math optimization question***From:*Steve Ellcey

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |