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

Robert L Krawitz rlk@tiac.net
Tue Sep 22 19:59:00 GMT 1998

   Date: Tue, 22 Sep 1998 13:31:41 -0700
   From: Yotam Medini <yotam@avanticorp.com>

   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?

Once you're doing the extra comparison, is it even faster anyway?
Anyway, this isn't correct; what happens if you have a NaN?  NaN's are
not numbers, so numerical comparisons are meaningless.

   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'.

	      .uaword	0x0 ! ~0.00000000000000000000e0
	      .type	 zeq,#function
	      .proc	04
	      !#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.

The problem is that sometimes you'll get the exception and sometimes
not, dependinging upon whether the operand is already in the FPU (in
which case it's almost surely faster to do the comparison in the FPU)
or if it's in memory.  If you always force it out to memory to perform
integer comparisons, you'll lose performance when the operand *is*
already in the FPU.

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

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf@uunet.uu.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

More information about the Gcc mailing list