This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: ix86 double alignment (was Re: egcs-1.1 release schedule)
- To: burley at gnu dot org
- Subject: Re: ix86 double alignment (was Re: egcs-1.1 release schedule)
- From: "David S. Miller" <davem at dm dot cobaltmicro dot com>
- Date: Tue, 23 Jun 1998 02:45:48 -0700
- CC: law at cygnus dot com, d dot love at dl dot ac dot uk, egcs at cygnus dot com
- References: <199806221829.OAA07477@melange.gnu.org>
Date: Mon, 22 Jun 1998 14:29:42 -0400 (EDT)
From: Craig Burley <burley@gnu.org>
A case we can't 64-bit align is:
real r(2)
double precision d1, d2
equivalence (r(1),d1)
equivalence (r(2),d2)
Regardless of whether this is stack, static, or even part of a common
block, we can't 64-bit align both d1 and d2. (Well, not without
an option to completely change the way we implement Fortran; I wonder
if Sun does that to support weird-but-conforming code on SPARCs,
such as the above.)
I can give some insight to this on certain cases on the Sparc.
The UltraSparc has specific high performance trap vectors dedicated to
handling the case where a double float load is done to an address
which is not aligned correctly. The UltraSparc users manual suggests
that if the compiler can determine that the likelyhood of bad
alignment is 50/50 or less, if should output the double float loads.
However there is an OS level side issue to this. Sparc is rather
strict about unaligned loads by default on most systems I know about.
However, most systems provide some way to tell the OS to "allow
unaligned memory accesses, and fix them up for the program".
This would need some investigation before such a scheme is enable in
egcs, so I'd say defer thinking about it until after the 1.1 release
happens.
Later,
David S. Miller
davem@dm.cobaltmicro.com