[Bug c/53134] New: Request for option to disable excess precision on i387

[Bug c/53134] New: Request for option to disable excess precision on i387

[bugdal at aerifal dot cx]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53134

             Bug #: 53134
           Summary: Request for option to disable excess precision on i387
    Classification: Unclassified
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: bugdal@aerifal.cx


Would it be possible to add to gcc an option to fully disable excess floating
point precision on i387? Basically it would work like this: any function
performing floating point arithmetic would be responsible for reading the
floating point control word, changing the precision to the right value for the
nominal type of the expression being evaluated, and restoring it afterwards
(before returning or making calls to any other function, to maintain
compatibility with code not compiled with this option).

Since even with the precision mode set correctly the exponent range of 387 fpu
registers still matches that of 80-bit long double, this mode would also imply
a store/load cycle after every single floating point operation, analogous to
-ffloat-store but on each step of calculation, not only on assignments. I
realize this would incur significant performance penalty, but for users trying
to obtain exact, reproducible, floating point results correctly rounded for the
type being used, it would be very useful. If the load/store cycle (stronger
version of -ffloat-store) were a separate option, the performance impact would
actually be extremely minimal when that part was turned off and only the
precision mode setting was turned on.

[Bug c/53134] Request for option to disable excess precision on i387

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53134

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-04-27 05:04:21 UTC ---
Have you tried -fexcess-precision=standard ?

[Bug c/53134] Request for option to disable excess precision on i387

[bugdal at aerifal dot cx]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53134

--- Comment #2 from Rich Felker <bugdal at aerifal dot cx> 2012-04-27 05:24:45 UTC ---
Thanks for the tip. I was not aware of that option (it's like -ffloat-store but
also applies to casts, so it makes GCC's behavior ISO C conformant), and it
seems some attention has been paid to making it actually correct. For instance,
it disables the intrinsic sqrt function which is non-conformant with excess
precision (the result is not correctly rounded). Overall quite impressive.

With that said, it's still a bit less/different than what I'm asking for. With
-fexcess-precision=standard, GCC on 387 behaves as a standards-conformant ISO C
compiler with FLT_EVAL_METHOD=2. The option I'm asking for would make it behave
as a standards-conformant ISO C compiler with FLT_EVAL_METHOD=0, which has 100%
well-defined bit-exact behavior for all non-transcendental operations. Or,
stated differently, it would give results identical to -msse2 -mfpmath=sse but
without requiring a CPU with sse2 instruction set support.

[Bug target/53134] Request for option to disable excess precision on i387

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53134

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |target

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-04-27 05:28:43 UTC ---
>without requiring a CPU with sse2 instruction set support.

What processor that is in production now that does not have SSE2?

[Bug target/53134] Request for option to disable excess precision on i387

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53134

--- Comment #4 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2012-04-27 10:23:42 UTC ---
On Fri, 27 Apr 2012, bugdal at aerifal dot cx wrote:

> Since even with the precision mode set correctly the exponent range of 387 fpu
> registers still matches that of 80-bit long double, this mode would also imply
> a store/load cycle after every single floating point operation, analogous to
> -ffloat-store but on each step of calculation, not only on assignments. I

I think it would also imply checks for subnormal results and fixups to 
avoid double rounding in those cases.

[Bug target/53134] Request for option to disable excess precision on i387

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53134

--- Comment #5 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2012-04-27 10:26:22 UTC ---
See also what I said in 
<http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00105.html>:

    The option naming leaves open the possibility of other options such as
    "none" if someone wishes to implement them.  ("none" would involve the
    compiler doing mode switching and adding code to deal with extra range
    and double rounding of subnormals.  There could also be an option to
    have extra range but not precision, again with the compiler inserting
    mode switches as needed.)  I am however doubtful of the use of such
    options; this patch deals with a major area where -std=c99 fails to
    implement standard semantics in default x86 configurations, but I'd
    expect people wanting particular semantics beyond a predictable
    version of C99 would use SSE.

[Bug target/53134] Request for option to disable excess precision on i387

[bugdal at aerifal dot cx]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53134

--- Comment #6 from Rich Felker <bugdal at aerifal dot cx> 2012-04-27 11:51:05 UTC ---
Joseph, you're right, and I don't see any way to handle the denormal issue
without really ugly and much slower wrapper code around each op...

[Bug target/53134] Request for option to disable excess precision on i387

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53134

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |manu at gcc dot gnu.org
         Resolution|                            |WONTFIX

--- Comment #7 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-04-28 10:30:57 UTC ---
So I guess WONTFIX then.

[Bug target/53134] Request for option to disable excess precision on i387

[bugdal at aerifal dot cx]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53134

--- Comment #8 from Rich Felker <bugdal at aerifal dot cx> 2012-04-28 23:14:57 UTC ---
I agree, sadly, that WONTFIX is probably the most appropriate action. At least,
like Andrew said, we're getting to the point where assuming it's okay to build
with -msse2 and -mfpmath=sse is reasonable.