Re: ix86 double alignment (was Re: egcs-1.1 release schedule)

[Craig Burley <burley@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.
[...]
>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.

Yes, let me make this clear.  I brought up SPARC only to illustrate
my awareness that this issue is a general one for all gcc targets
in theory at least and in practice for at least two targets (x86
and SPARC), probably others as well (`sh', whatever that is, already
seems to have its own work done in this area...can someone send me
a `sh' machine please? ;-).

I am *not* recommending any of the changes we're discussing actually
applying to code generation on SPARCs at all, at least not in the
short term (1.1).

In particular, while this align-doubles-properly-or-performance-will-
really-really-suck issue has *frequently* come to my attention for
the x86 architecture, basically *never* can I recall anyone complaining
about not being able to compile real Fortran code using standard-
conforming (but, as Dave Love rightly points out, nonportable due
to machines like SPARC) constructs like the one I illustrated above.

My impression: SPARC users, even of g77, have already been "trained"
by Sun to not expect some weird force-bad-alignment code to work
on that architecture.  So they don't complain to us, either.

(And, yes, there is a way to "fix" this problem: provide a command-line
option that the compiler handles by making all ints and floats 64-bit,
all doubles 128-bit, and adjusting the run-time libraries and so on
accordingly.  Not that the *precision* goes up, just that the Fortran
INTEGER, LOGICAL, and REAL types suddenly have 32 useful bits and 32
junk bits in 64 bits of space, DOUBLE PRECISION and COMPLEX have 64+64
bits, and so on.  With only a relatively small amount of hair, this
makes full Fortran standards conformance possible, and makes most
data needs expand by a factor of two with no increase in precision or
range and a general decrease in run-time performance.  A great way to
discourage people from insisting that their old codes run without
modification.  Can't recall what I've been told, if anything, about
whether Sun provides such an option in any of its Fortran compilers.
Perhaps just the *threat* of "solving" this problem this way is all
that has ever been needed, like the cold-war MAD policy regarding use
of nuclear armaments.  But I can't recall anybody asking for this option
in g77, though I might be so quick to say "fine, send us lots of money"
that I forgot all about any such requests.  :)

So, the tempting thing some people have thought is "well, SPARC
users are used to a `broken' Fortran implementation for years,
being happier with the performance gains; why not foist this on
Intel users?"  Unfortunately, the existing user base, library
code, and iron base makes this worth solving for only newer
instances of those, but not worth breaking for the older ones.

The upshot: when [56]86 users aren't using "dangerous" options like
`-malign-double', we still need to do 64-bit alignment wherever
possible but without breaking compatibility to get decent
performance.

BTW, as much as I want this problem "cured" for [56]86 users in egcs
1.1, I *really* hope the libm performance problems on Alpha are
generally fixed by the time such a version of egcs is released,
because it disturbs me a bit that we might make [56]86 appear
even better price/performance-wise than Alphas than they have in
the past, especially since we *know* we can speed up the Alphas
more than the [56]86 just by fixing just the software.  (And,
intentionally, I've kept the Alpha architecture manual within
reach, but not the ix86 one so, for over a year now.  :)

        tq vm, (burley)