[cfe-dev] Floating-point performance question

[Chris Lattner]

On Sep 6, 2013, at 1:18 PM, Richard Hadsell <hadsell at blueskystudios.com> wrote:

> On 09/06/2013 12:09 PM, Stephen Canon wrote:
>> On Sep 6, 2013, at 8:31 AM, Hal Finkel <hfinkel at anl.gov> wrote:
>> 
>>> On 09/06/2013 11:19 PM, Richard Hadsell wrote:
>>> 
>>> We changed our code to use 'exp2 (x)' instead of 'pow (2.0, x)' and
>>> verified that the G++ version now calls feholdexcept. We'll also run
>>> our benchmarks again to compare Clang++ with G++ on our modified
>>> code.
>>> 
>>> So, the question for Clang developers is: how can we avoid the
>>> optimization that converts 'pow (2.0, x)' to 'exp2 (x)'?
>>> This happens in Transforms/Utils/SimplifyLibCalls.cpp -- Maybe we should add a function to TargetLibraryInfo in order to mark exp2 as expensive on some platforms?
>> This is really a library bug — exp2(x) should be at least as fast as pow(2,x) with any sane implementation (in particular, the library writers can implement exp2 by calling pow(2,x), so there’s no excuse for it to be slower).  That said, it might be worth working around in the meantime.
> 
> Our workaround: 'const double TWO = 2.;' is defined in a library separate from all our code.  The compiler can't change 'pow (TWO, x)' to 'exp (x)'.  This improved performance by quite a bit.  I'll address the next performance issue in a separate message.
> 
> It would still be nice to have some control over whether translations of math functions are performed automatically by the compiler.  Are there many of them?
> 
> Compiler options could help deal with this kind of library implementation problem.

IMO, if glibc's implementation of exp2 is so bad, LibCall info should get a bit to indicate this.  This could disable pow(2 -> exp2, and could enable transformations from exp2(x) -> pow(2,x).

-Chris