[llvm-commits] Fix Bug 13574: Add more double float shrinking optimizations

[Weiming Zhao]

I agree. They are different from floor, round, etc. 

For the transformation, we can limit the condition to both the input and
output be single FP and guard them with fast-math.

 

 

From: Stephen Canon [mailto:scanon at apple.com] 
Sent: Wednesday, August 15, 2012 1:49 PM
To: Weiming Zhao
Cc: llvm-commits at cs.uiuc.edu
Subject: Re: [llvm-commits] Fix Bug 13574: Add more double float shrinking
optimizations

 

We want functions with integral-valued results (floor, ceil, round, rint,
nearbyint, trunc) to get these transformations universally; because the
result is always exactly representable, this transformation does not change
the resulting values.

 

For functions that can return inexact results (cos, sin, pow, exp, log,
etc), this should be defeatable.  There are platforms with "skanky" math
libraries that may have 10+ ulps of error in these single-precision
routines; using the double-precision versions instead is a common idiom for
developers to get better quality results.

 

The transform that I'm especially concerned about, is where the result is
not casted back to float:

 

            func(floatval) --> (double)funcf(floatval)

 

this should simply not done for the inexact operations (it discards 29 bits
of precision!), but is fine for the functions that produce integral results.

 

Someone who knows the guts here may have a better idea, but it seems to me
that we should have two distinct optimizations (one for
floor/ceil/round/etc, and one for cos/sin/pow/etc).

 

- Steve

 

On Aug 15, 2012, at 4:37 PM, Weiming Zhao <weimingz at codeaurora.org> wrote:





Hi Steve,

 

Yes, it transforms (float)func((double) val) to funcf(v), which saves 2
conversions and possibly cheaper math  function.

 

GCC O1 does the same transformation. For LLVM, we can guard the
transformations by flags like fast-math or a separate flag.

Furthermore, such transformation can be disabled by default. So it also
solves the performance issue of double/single FP on some platforms.

 

Thanks,

Weiming

 

From: Stephen Canon [mailto:scanon@ <http://apple.com> apple.com] 
Sent: Wednesday, August 15, 2012 11:54 AM
To: Weiming Zhao
Cc:  <mailto:llvm-commits at cs.uiuc.edu> llvm-commits at cs.uiuc.edu
Subject: Re: [llvm-commits] Fix Bug 13574: Add more double float shrinking
optimizations

 

Do I understand correctly that this optimization would transform
cos((double)floatval) --> (double)cosf(floatval)?  That's not a acceptable
transformation, numerically.

 

One should also consider that there are a number of platforms supported by
LLVM (not naming names) on which the float variants of libm functions are
significantly *slower* than the double-precision variants.

 

- Steve

 

On Aug 15, 2012, at 2:33 PM, Weiming Zhao < <mailto:weimingz at codeaurora.org>
weimingz at codeaurora.org> wrote:






Hi,

 

This patch fixes  <http://llvm.org/bugs/show_bug.cgi?id=13574>
http://llvm.org/bugs/show_bug.cgi?id=13574

 

Current LLVM only supports 5 double->float shrinking optimizations
(floor->floorf, ceil->ceilf,round->roundf, rint->rintf() and
nearbyint->nearbyintf).

 

This patch adds more math functions, for example, pow->powf, sin->sinf,
cos->cosf, etc.

 

In this patch:

1.     Since cos(), pow() and exp2() already have their own optimizers:
CosPot, PowOpt and Exp2Opt, respectively, I let them inherit from
UnaryDoubleFPOpt and in their CallOptimizer(), I let them to call the base
class's CallOptimizer() first.

For this change, I have to hoist the definition of UnaryDoubleFPOpt ahead of
CosOpt.

 

2.       Since some functions are not available on Windows, I updated
TargetLibraryInfo to mark them as unavailable.

 

3.       A unit test case is updated to test this patch.

 

Please help to review them.

 

Thanks,

Weiming

<0001-Bug-13574-More-double-float-shrinking-optimizations-f.patch>__________
_____________________________________
llvm-commits mailing list
 <mailto:llvm-commits at cs.uiuc.edu> llvm-commits at cs.uiuc.edu
 <http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits>
http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120815/72805a8b/attachment.html>