This is the mail archive of the 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]

Re: 11706 vs ([lno] Canonical iv creation)

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

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.


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,


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]