Re: FWD: FLOATING-POINT CONSISTENCY, -FFLOAT-STORE, AND X86

[Craig Burley <burley at gnu dot org>]

>This would imply that for now, since the spill width is 64 bits &
>can't immediately be changed, that the FPU be set to double precision,
>and when gcc is capable of spilling other widths then the spill width
>should be increased to 80 bits.

Okay, not a bad idea, but to set the FPU to double precision without
breaking existing code, the compiler would have to save the FPU
setting on entry to any procedure, ensure that it's restored when
that procedure returns, and restore it prior to any call, then
re-save and re-set it upon that call's return.  (And we cross our fingers
that the call wasn't made specifically to change the FPU settings,
to be made effective in the current routine, since we'd be breaking
that sort of thing.)

Somehow I don't think slowing FP performance to a crawl in gcc will
be considered acceptable, and I believe setting the FPU this way would
indeed slow performance to a crawl.

>It'd be nice to allow it to be
>selectable, but then you're really getting into what Craig Burley was
>talking about - namely different compiled code could have different
>spill widths and mucking with the FP control word could cause all
>sorts of havoc.

Even if you *don't* allow it to be selectable, you get into all that
as soon as you decide to set the FPU to 64 bits, or even to 80 bits.

AFAIK, the current assumption throughout the x86 world, except for
"leaf" nodes (codes, object files, libraries all produced by a
particular compiler vendor, generally incompatible with others),
is that the FPU is left in the default of 80 bits, though maybe set
by main() (or main's caller).

So IMO if we even changed gcc to explicitly set the FPU to *80* bits
on entry to any procedure, we'd be introducing potential problems
in some cases -- for users who've carefully ensured their code, when
compiled, worked fine when the FPU was set to 64 or 32 bits, and don't
realize gcc is now re-setting the FPU out from under them.

Put simply: we *cannot* fiddle with the FPU settings in any global sense,
without simultaneously "taking over" the entire codebase that gets
linked with gcc-produced code, something that I think is completely
infeasible compared to, for example, just implementing my proposal
(which isn't easy, but at least doesn't require a few million man-hours).

The most optimal step at this point still seems to be to continue to
gather (credible) information, and perhaps to adopt my proposal (which
calls for spilling FP registers to 80-bit temporaries -- presumably
actually 128-bit temps -- instead of 64-bit ones) as soon as feasible,
with an option to revert to the old behavior of spilling to 64-bit temps.

I do think that option name should be crafted to be precision-specific,
e.g.:

  -fchop-fp-spills
  -fchop-fp-spills-64
  -fchop-fp-spills-32

The first means "chop down to actual type of operation based on its
operands", the second means "chop down to 64 bits", etc.  I think the
first would mean the current behavior as well, but we should be careful
to note any differences, and perhaps account for them (via a slightly
different option, such as -fchop-fp-spills-old).

        tq vm, (burley)