Questions about "Handle constant exponents." in gcc/builtins.c

Questions about "Handle constant exponents." in gcc/builtins.c

[Dominique Dhumieres]

In the block "Handle constant exponents." in gcc/builtins.c, the condition
!optimize_size has been replaced with optimize_insn_for_speed_p () between
gcc 4.3 and 4.4, but I have not been able to find when and why.
Does anybody remembers the when and why?

This change make the optimization sensitive to PR40106 and unless it has
compeling reasons it should be reverted in this piece of code.

My second question is why using optimize_size? I think it would be better
to define an upper bound instead of POWI_MAX_MULTS that depends on the kind
of optimisation. I cannot see any situation in which sqrt(a) would not be
better that pow(a,0.5) for speed, size, and accuracy.

TIA

Dominique

Re: Questions about "Handle constant exponents." in gcc/builtins.c

[Richard Guenther]

On Tue, Mar 16, 2010 at 4:11 PM, Dominique Dhumieres <dominiq@lps.ens.fr> wrote:
> In the block "Handle constant exponents." in gcc/builtins.c, the condition
> !optimize_size has been replaced with optimize_insn_for_speed_p () between
> gcc 4.3 and 4.4, but I have not been able to find when and why.
> Does anybody remembers the when and why?
>
> This change make the optimization sensitive to PR40106 and unless it has
> compeling reasons it should be reverted in this piece of code.
>
> My second question is why using optimize_size? I think it would be better
> to define an upper bound instead of POWI_MAX_MULTS that depends on the kind
> of optimisation. I cannot see any situation in which sqrt(a) would not be
> better that pow(a,0.5) for speed, size, and accuracy.

pow (a, 0.5) is always expanded to sqrt(a).  It is when we require
additional multiplications, pow (a, n) -> sqrt (a) * a**(n/2), that
optimize_insn_for_speed_p () is checked.

Richard.

> TIA
>
> Dominique
>
>

Re: Questions about "Handle constant exponents." in gcc/builtins.c

[Vincent Lefevre]

On 2010-03-16 16:18:17 +0100, Richard Guenther wrote:
> pow (a, 0.5) is always expanded to sqrt(a).

This violates the ISO C99 standard for -0.0.

According to N1256, F.9.4.4:

  pow(±0, y) returns +0 for y > 0 and not an odd integer.

So, pow(-0.0, 0.5) should return +0. But sqrt(-0.0) should return -0
according to the IEEE 754 standard (and F.9.4.5 from ISO C99).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: Questions about "Handle constant exponents." in gcc/builtins.c

[Vincent Lefevre]

On 2010-03-18 14:43:39 +0100, Vincent Lefevre wrote:
> This violates the ISO C99 standard for -0.0.
> 
> According to N1256, F.9.4.4:
> 
>   pow(±0, y) returns +0 for y > 0 and not an odd integer.
> 
> So, pow(-0.0, 0.5) should return +0. But sqrt(-0.0) should return -0
> according to the IEEE 754 standard (and F.9.4.5 from ISO C99).

I've reported the problem:

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43419

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: Questions about "Handle constant exponents." in gcc/builtins.c

[Michael Matz]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 933 bytes --]

Hi,

On Thu, 18 Mar 2010, Vincent Lefevre wrote:

> On 2010-03-16 16:18:17 +0100, Richard Guenther wrote:
> > pow (a, 0.5) is always expanded to sqrt(a).
> 
> This violates the ISO C99 standard for -0.0.
> 
> According to N1256, F.9.4.4:
> 
>   pow(±0, y) returns +0 for y > 0 and not an odd integer.
> 
> So, pow(-0.0, 0.5) should return +0. But sqrt(-0.0) should return -0
> according to the IEEE 754 standard (and F.9.4.5 from ISO C99).

Yes, and I don't know why they specified it like that.  After all 
(-0)*(-0)==+0 (not ==-0), so the above definition is internally 
insonsistent.  Defining sqrt(-0) as +0 would be equally inconsistent, but 
at least agree with the pow(-0, 0.5) result.

But unfortunately you are right, this expansion can only be done for 
-fno-signed-zeros.  (FWIW the general expandsion of pow(x,N/2) where N!=1 
is already guarded by unsafe_math, but for N==1 we do it unconditionally).


Ciao,
Michael.

Re: Questions about "Handle constant exponents." in gcc/builtins.c

[Vincent Lefevre]

On 2010-03-18 15:32:04 +0100, Michael Matz wrote:
> > So, pow(-0.0, 0.5) should return +0. But sqrt(-0.0) should return -0
> > according to the IEEE 754 standard (and F.9.4.5 from ISO C99).
> 
> Yes, and I don't know why they specified it like that.  After all 
> (-0)*(-0)==+0 (not ==-0), so the above definition is internally 
> insonsistent.  Defining sqrt(-0) as +0 would be equally inconsistent, but 
> at least agree with the pow(-0, 0.5) result.

sqrt(-0) was defined first by the IEEE 754 standard in 1985.
AFAIK, -0 was chosen to allow a hack for some convention in
interval arithmetic (there may be other reasons). pow(-0, y)
was defined by the C committee.

> But unfortunately you are right, this expansion can only be done for
> -fno-signed-zeros. (FWIW the general expandsion of pow(x,N/2) where
> N!=1 is already guarded by unsafe_math, but for N==1 we do it
> unconditionally).

If GCC is able to track range of values, the transformation could
be allowed when it can be proved that the value -0 is not possible
(e.g. when x > 0).

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: Questions about "Handle constant exponents." in gcc/builtins.c

[Nathan Froyd]

On Thu, Mar 18, 2010 at 04:34:56PM +0100, Vincent Lefevre wrote:
> On 2010-03-18 15:32:04 +0100, Michael Matz wrote:
> > But unfortunately you are right, this expansion can only be done for
> > -fno-signed-zeros. (FWIW the general expandsion of pow(x,N/2) where
> > N!=1 is already guarded by unsafe_math, but for N==1 we do it
> > unconditionally).
> 
> If GCC is able to track range of values, the transformation could
> be allowed when it can be proved that the value -0 is not possible
> (e.g. when x > 0).

That would be useful, and other language implementations do similar
things.  GCC's VRP (value range propagation pass) does not handle
floating-point values at the moment, though.

-Nathan

Re: Questions about "Handle constant exponents." in gcc/builtins.c

[Joseph S. Myers]

On Thu, 18 Mar 2010, Vincent Lefevre wrote:

> On 2010-03-18 15:32:04 +0100, Michael Matz wrote:
> > > So, pow(-0.0, 0.5) should return +0. But sqrt(-0.0) should return -0
> > > according to the IEEE 754 standard (and F.9.4.5 from ISO C99).
> > 
> > Yes, and I don't know why they specified it like that.  After all 
> > (-0)*(-0)==+0 (not ==-0), so the above definition is internally 
> > insonsistent.  Defining sqrt(-0) as +0 would be equally inconsistent, but 
> > at least agree with the pow(-0, 0.5) result.
> 
> sqrt(-0) was defined first by the IEEE 754 standard in 1985.
> AFAIK, -0 was chosen to allow a hack for some convention in
> interval arithmetic (there may be other reasons). pow(-0, y)
> was defined by the C committee.

And the same rule on pow(-0, y) is present in 754-2008 (I don't know 
whether this was deliberately following the C definition, or deciding 
independently that this was the right definition, but you may know as a 
listed member of the balloting committee).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Questions about "Handle constant exponents." in gcc/builtins.c

[Vincent Lefevre]

On 2010-03-18 15:49:05 +0000, Joseph S. Myers wrote:
> And the same rule on pow(-0, y) is present in 754-2008 (I don't know 
> whether this was deliberately following the C definition, or deciding 
> independently that this was the right definition, but you may know as a 
> listed member of the balloting committee).

There were many discussions concerning the pow() function and several
changes, but I don't know who decided at the end. I think that anyone
agreed with pow(-0, y) returning +0 for y > 0 not an odd integer (due
to the absence of an unsigned 0, +0 is generally chosen). The case
pow(-1,inf) was much more controversial (it seems that most people
wanted NaN, while I preferred the C behavior for consistency with the
large arguments).

Also note that there are 3 power functions: pown, pow and powr.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: Questions about "Handle constant exponents." in gcc/builtins.c

[Dominique Dhumieres]

May I remind my original question:

> In the block "Handle constant exponents." in gcc/builtins.c, the condition
> !optimize_size has been replaced with optimize_insn_for_speed_p () between
> gcc 4.3 and 4.4, but I have not been able to find when and why.
> Does anybody remembers the when and why?

This change has been commited by someone and should have been approved by
someone else.

TIA

Dominique

Re: Questions about "Handle constant exponents." in gcc/builtins.c

[Jakub Jelinek]

On Thu, Mar 18, 2010 at 04:07:28PM +0100, Dominique Dhumieres wrote:
> May I remind my original question:
> 
> > In the block "Handle constant exponents." in gcc/builtins.c, the condition
> > !optimize_size has been replaced with optimize_insn_for_speed_p () between
> > gcc 4.3 and 4.4, but I have not been able to find when and why.
> > Does anybody remembers the when and why?
> 
> This change has been commited by someone and should have been approved by
> someone else.

svn blame is your friend, then finding a patch on gcc-patches from that day
up to a few days before the commit.

	Jakub

Re: Questions about "Handle constant exponents." in gcc/builtins.c

[Dominique Dhumieres]

> Google is your friend...

Thanks Jack. As you can see in comment #46 of pr40106, I have found
my own way. In my previous attempts I have made two mistakes:
(1) I tried to use the search engine of the gcc mailing lists that
kept parsing optimize_insn_for_speed_p as if the _ were spaces.
(2) I did not realized that the history in only kept in trunk.

> svn blame is your friend, ...

When I report a pr I am not interested at all to blame anything
or anybody, only to see the pr fixed ASAP;-)

Cheers,

Dominique

PS For the ongoing discussion about the equivalence between
sqrt(x) and pow(x, 0.5), I'll only say that some influent
people should learn some basic math!