Fixing ilogb()

[Bruce Evans]

On Sun, 9 May 2004, I wrote:

> ...
> % @@ -43,11 +43,27 @@
> %  	subl	$4,%esp
> %
> %  	fldl	8(%ebp)
> % +	fxam
> % +	fnstsw	%ax
> % +	sahf
>
> This is the main runtime overhead.  I think it can mostly be avoided by
> checking the return value.  ilogb() can only be INT_MIN after overflow
> or other conversion errors (check this).  There 3 cases:
> - logb(0) = -Inf; fistpl(-Inf) = INT_MIN + IE
> - logb(Inf) = Inf; fistpl(-Inf) = INT_MIN + IE
> - logb(NaN) = same NaN; fistpl(NaN) = INT_MIN + IE
> After finding one of these rare cases, the exact case still needs to be
> determined by looking at the original value or the result of fxtract.
> Then fucom with 0 should be a faster way to do the classification.  A
> full classification is not needed sice denormals are not special here
> and unsupported formats are unsupported here too.

Another thing to decide is whether the exception flags should be set (or
not) to indicate overflow.  I think they should be.  Checking after doing
the operation sets them; checking before does not.  The standard is not
clear.  It says that the result is equivalent to (int)logb() for the
non-overflowing cases but has special rules with unusual wording for
the overflowing cases.  It says "If x is zero they [the ilogb functions]
compute the value FP_ILOGB0. ..."  Computation a constant value is
different from returning it, so this can be interpreted as saying that
the exception flags may be set.  I think there's a meta-rule that math
functions set execption flags where appropriate.

Bruce