Add an alternative view of the bits in an 80-bit long double (64+16

instead of 32+32+15+1) on all arches that have such long doubles (amd64,
ia64 and i386).  Large objects should be be accessed in large units,
and the 32+32+15+1[+padding] decomposition asks for almost the opposite
of that, sometimes resulting in very slow accesses depending on how
well the compiler ignores what we ask for and converts to the best
units for the given machine.  E.g., on Athlons, there is a 10-20 cycle
penalty for accessing the middle 32-bit word immediately after an
80-bit store.

Whether actually using the alternative view is better is very machine-
dependent.  A 32+32+16 view is probably best with old 32-bit systems
and gcc through 4.2.1.  The compiler should mostly avoid the view and
generate best accesses, but gcc-4.2.1 is far from doing that.  I think
64+16 is best for now.  Similarly for doubles -- they should be using
64+0 especially on 64-bit machines, but fdlibm uses 32+32 extensively
for them.  Fortunately, in 64-bit mode for doubles, gcc already ignores
the 32+32-bit view and generates best accesses in many cases.

1 files changed, 6 insertions, 1 deletions

diff --git a/lib/libc/amd64/_fpmath.h b/lib/libc/amd64/_fpmath.h
index 8f8cf6f..c2a7384 100644
--- a/lib/libc/amd64/_fpmath.h
+++ b/lib/libc/amd64/_fpmath.h
@@ -36,6 +36,11 @@ union IEEEl2bits {
 		unsigned int	junkl	:16;
 		unsigned int	junkh	:32;
 	} bits;
+	struct {
+		unsigned long	man	:64;
+		unsigned int	expsign	:16;
+		unsigned long	junk	:48;
+	} xbits;
 };
 
 #define	LDBL_NBIT	0x80000000
@@ -47,4 +52,4 @@ union IEEEl2bits {
 #define	LDBL_TO_ARRAY32(u, a) do {			\
 	(a)[0] = (uint32_t)(u).bits.manl;		\
 	(a)[1] = (uint32_t)(u).bits.manh;		\
-} while(0)
+} while (0)