wish: optimize (x > 0.) floating point comparison.

Yotam Medini yotam@avanticorp.com
Tue Sep 22 19:31:00 GMT 1998


>   Date: Tue, 22 Sep 1998 16:04:20 -0400
>   From: Robert L Krawitz <rlk@tiac.net>
>   Cc: egcs@cygnus.com
>
>      Date: Tue, 22 Sep 1998 08:55:30 -0700
>      From: Yotam Medini <yotam@avanticorp.com>
>
>      ...
>      I believe that floating-point comparisons (<, >, <=, >=) with 0.0 is
>      very frequent and worth the trouble of optimizing using the sign bit
>      within the (platform dependent) floating-point representation or some
>      other machine instruction.
>
>   That's not correct.  Consider -0.0 (all zeroes in the mantissa and
>   exponent, 1 in the sign bit).  This should compare >= 0 (it is, after
>   all, mathematically equal to zero).  Furthermore, it would not take an
>   exception if the bits do not in fact represent a valid number.

Good point.
I am not familier with the (IEEE?) standard of floating-point representation.
May be a the following pseudo code (with lazy || evaluation)
    bool positive(double x)
    { return((highBit(x) == 0) || ((bitwise)x == (bitwise)(-0.0))); }
is still faster?

Actually, a preliminary question should be if
there is a better way to check for equality to zero than
using 'ldd' (of zero complement?) and 'fcmpd'.

   .LLC5:
	   .uaword	0x0 ! ~0.00000000000000000000e0
     .....
     .....
	   .type	 zeq,#function
	   .proc	04
   zeq:
	   !#PROLOGUE# 0
	   add %sp,-120,%sp
	   !#PROLOGUE# 1
	   sethi %hi(.LLC5),%g2
	   ldd [%g2+%lo(.LLC5)],%f2
	   std %o0,[%sp+96]
	   ldd [%sp+96],%f4
      	   fcmpd %f4,%f2
     ....

Math exception - I would gladly lose the exception handling
for faster code if I can turn it back on with appropriate debugging flags.

>   Robert Krawitz <rlk@tiac.net>	       http://www.tiac.net/users/rlk/

-- yotam



More information about the Gcc mailing list