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

[Paolo Carlini <pcarlini at suse dot de>]

Gabriel Dos Reis wrote:

> It would be misleading to let people believe that is only about
> "cleaness".  The raison d'être of pow(T, int) is precesily that common
> implementations of pow(T, floating-point) try to recover an
> information they don't have access to but which where available at the
> call site, namely whether the exponent is integer or not and apply the
> appropriate algorithm.  The pow() we are discussing was provided as a
> way to communicate that information to the library.  
> Forwarding the call back again to pow(T, floating-point) defeats the
> whole purpose of pow(T, int).  It is pessimization -- note calls to
> pow() are not just with constant integers.  I don't see that
> as improvement.

Well, Gaby, I don't want to discuss this issue more. After all, you
gonna take the responsability for the performance of pow(T, int) in 3.4, 
not me.

But, again, if we want to have a pragmatic spirit, not only based on
questions of principle, your latter sentences are simply false. Have you 
actually tried passing to the built-in pow an integer exponent? Have you 
followed Roger's beautiful work on that builtin? I think so. Why now you 
are denying that gcc's builtin pow is able to take into account the 
integer nature of its argument and optimize the call in an excellent 
way? With just a 3-line patch the generated code would be much better 
than now, nobody in the world would notice the the difference from a 
correctness point of view, and that's it.

Are you sure that someone will actually implement for 3.5 the 
__builtin_powi that you are talking about? Will you make sure that this 
will actually happen? Are you doing something for that beyond verbal 
advocacy? Otherwise we'll keep on producing bad code for 3.5 too, only 
because we have the "dream" of an incredibly cool future approach...

Paolo.