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