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

[Stephen Canon]

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 at apple.com] 
> Sent: Wednesday, August 15, 2012 11:54 AM
> To: Weiming Zhao
> Cc: 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 <weimingz at codeaurora.org> wrote:
> 
> 
> Hi,
>  
> This patch fixes 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
> llvm-commits at cs.uiuc.edu
> 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/dbcc56cb/attachment.html>