Run-time noise from fp-bit:df_to_sf (truncdfsf2).

Run-time noise from fp-bit:df_to_sf (truncdfsf2).

[Hans-Peter Nilsson]

I don't think this has been reported before, and I'm not sure any code
should change.  I mean this as a heads-up only.  The run-time of the
fp-bit.c truncdfsf2 implementation is noisy; it depends on stack-contents.
That function is short enough to quote:

SFtype
df_to_sf (DFtype arg_a)
{
  fp_number_type in;
  USItype sffrac;
  FLO_union_type au;

  au.value = arg_a;
  unpack_d (&au, &in);

  sffrac = in.fraction.ll >> F_D_BITOFF;

  /* We set the lowest guard bit in SFFRAC if we discarded any non
     zero bits.  */
  if ((in.fraction.ll & (((USItype) 1 << F_D_BITOFF) - 1)) != 0)
    sffrac |= 1;

  return __make_fp (in.class, in.sign, in.normal_exp, sffrac);
}

If arg_a is zero, the function unpack_d will return with in.sign set,
in.class = CLASS_ZERO, and the rest unaltered (garbage; whatever was on
stack).  The if-statement that follows the call then depends on the
garbage contents of in.fraction.ll.  Note, the truncdfsf2 *result* does
not depend on this erratic behavior.

If your target uses fp-bit.c and you're into testing run-time behaviour
for all minimal changes (who doesn't?) and such a change makes a
difference that propagates to stack contents (most changes do), you'll
likely see noise in your run-time numbers for almost any test that
includes floating-point calculations.

To wit, this can turn that small change you just did, that could only have
a positive effect on run-time if any at all, to show net negative numbers.
The effect should be small for most programs (ghostscript-5.50 in my
case), but as an anomaly it's still a cause for investigation.

I can't see any obvious code correction that will not likely have a
negative run-time effect, but maybe this message will save someone some
head-scratching.  Valgrind-like simulators will warn for "conditional jump
or move depends on uninitialised value" provided that simulator marks
memory that falls below the stack pointer as undefined, like valgrind does.

I'm interested in other similar sources of noise in gcc or nearby that
people have found.  (Except for cases of using pointers as input to a hash
function.  Those are just bugs and should be fixed.)

brgds, H-P

Re: Run-time noise from fp-bit:df_to_sf (truncdfsf2).

[Daniel Jacobowitz]

On Sat, Dec 06, 2003 at 03:39:26PM +0100, Hans-Peter Nilsson wrote:
> I can't see any obvious code correction that will not likely have a
> negative run-time effect, but maybe this message will save someone some

I can.  Add a comment :)

> head-scratching.  Valgrind-like simulators will warn for "conditional jump
> or move depends on uninitialised value" provided that simulator marks
> memory that falls below the stack pointer as undefined, like valgrind does.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Run-time noise from fp-bit:df_to_sf (truncdfsf2).

[Hans-Peter Nilsson]

On Sat, 6 Dec 2003, Daniel Jacobowitz wrote:
> On Sat, Dec 06, 2003 at 03:39:26PM +0100, Hans-Peter Nilsson wrote:
> > I can't see any obvious code correction that will not likely have a
> > negative run-time effect, but maybe this message will save someone some
>
> I can.  Add a comment :)

Doh!  Of course.  That is, if you extend "code change" to mean
"any source code change".  Ok, there goes the element of obviousness...

(Actually I'm trying out an (actual) code change to see if
there's hope for the average case.)

brgds, H-P