cvs commit: src/sys/i386/include _types.h

[David Schultz]

On Wed, Mar 05, 2008, Colin Percival wrote:
> Bruce Evans wrote:
> > On Wed, 5 Mar 2008, Colin Percival wrote:
> >> Bruce Evans wrote:
> >>>   Change float_t and double_t to long double on i386.
> >>
> >> Doesn't this have a rather severe performance impact on any code which
> >> uses double_t?
> > 
> > No.  As mentioned in the commit message, this has no performance effect
> > except in cases where it avoids compiler bugs.  [...] if you use long double
> > for memory variables then you get a severe performance impact and some
> > space loss for the load instruction, since loading long doubles is
> > much slower than loading doubles (about 4 times slower on Athlons).
> 
> Either I'm misunderstanding something, or you seem to be disagreeing with
> yourself here... if I have the following code
> 
> double_t foo, bar, foobar;
> foobar = foo + bar;
> 
> then prior to this change the processor loads and stores doubles, while
> after this change the processor loads and stores long doubles, with the
> associated performance penalty.

If gcc actually implemented IEEE 754R / C99 / LIA1 correctly, then
when compiling something like 'double x = y' would require it to
store the value to memory and then reload it to force it to 53-bit
precision. The whole point of double_t is to allow the programmer
to ask for a variable that is "at least double precision", so that
the compiler isn't forced to clip everything to double precision
if it's inefficient to do so. However, gcc doesn't compile the above
expression correctly, and FreeBSD works around the problem by
setting the default rounding mode to 53 bits, which is why it's
pointless to increase the size of double_t.