11706 vs ([lno] Canonical iv creation)

[Richard Guenther]

Roger Sayle wrote:
> On Sat, 13 Mar 2004, Richard Guenther wrote:
> 
>>>Really interesting issue...
>>>
>>>Anyway, from a practical point of view I'm not really worried, since:
>>>
>>>1- Glibc uses internally the very same algorithm, at least on x86 (just
>>>   checked).
>>>
>>>2- Which requires O(log n) multiplications and is discussed by Knuth in
>>>   Sec. 4.6.3 of the second volume. You can find it almost *everywhere*,
>>>   for instance also in SGI's power.
>>
>>So there is no point in not optimizing ::pow(x, 4) without -ffast-math?
> 
> There is a potential accuracy problem, which is why GCC doesn't inline
> ::pow(x,4) without -ffast-math.

[snip]

> Whether libstdc++-v3 can be more pragmatic than GCC about system library
> accuracy, and even whether -ffast-math is a reasonable default for the
> compiler (as its is with several commercial compilers), are larger
> arguments.  I doubt anyone would practically use a method more accurate
> than two multiplications to implement pow(x,4).  So I agree with Paolo's
> disclaimer "from a practical point of view I'm not really worried.." :>
> 
> I hope this helps,

I'm aware of the rouding problems and am not worried about these.  But I 
am worried about having ::pow() and std::pow() produce different results 
for same arguments.  So the question is, does the standard say anything 
about this?  Also, as ::pow() with -ffast-math optimizes better than 
std::pow() for constant exponent, the question is again why we don't use 
::pow() for std::pow() ... which would also be faster in compilation speed.

We might even use SIMD operations (if available) to speed up -ffast-math 
::pow()?

Thanks for the explanations,

Richard.