Re: biggest alignment for sysv4.h altivec

[Geoff Keating <geoffk at geoffk dot org>]

> cc: gcc-patches@gcc.gnu.org
> Date: Fri, 08 Mar 2002 23:08:18 -0500
> From: David Edelsohn <dje@watson.ibm.com>
> 
> >>>>> Geoff Keating writes:
> 
> | I would look at it the other way.  Why should BIGGEST_ALIGNMENT
> | differ?  It doesn't change when we switch on -msoft-float, even though
> | if we don't have hardware doubles then we don't need 64-bit alignment.
> 
> 	The Altivec ABI is an extension to the SVR4 and Darwin/AIX ABIs.
> It increases the biggest alignment to 128 bits.
> 
> 	-msoft-float is not a new or extended ABI.  It is the original ABI
> with FPRs disabled and floating point emulated in GPRs.  It is intended to
> be compatible with the original ABI and the original ABI's alignment
> rules. 
> 
> 	The two issues are not similar enough to use as justification or
> precedent for the other.
> 
> 	  BIGGEST_ALIGNMENT needs to change because the Altivec ABI says
> that it is different.  One cannot uniformly change BIGGEST_ALIGNMENT to
> 128 because that is not what the SVR4 ABI specifies.  One needs the
> conditional as Aldy has proposed.

That's an interesting point, and helped clarify my thinking on this a
lot.  Thanks!

I presume you meant EABI when you said SVR4 ABI.  The SVR4 ABI has
always had 128-bit alignment of the stack frame and other objects.

The published EABI also has certain objects that do require 128-bit
alignment.  Although the stack is not 128-bit aligned, for
compatibility with the SVR4 ABI it has always been the case that, if
'long double' was implemented (as in the -mlong-double-128 flag), then

struct x {
  int a;
  long double d;
};

has had 'd' aligned to a 128-bit boundary (even though if it was on
the stack or a global it would be aligned only to a 64-bit boundary,
and in fact there's no guarantee the structure will be properly
aligned).  I don't think we do this properly now; we should, and one
step towards doing it is changing BIGGEST_ALIGNMENT.

And now, in a neat twist of logic, I can argue that -mno-long-double-128
is just like -msoft-float.

We have different restrictions on changing GCC's EABI implementation
than changing the SVR4 ABI implementation, especially if it's fixing
bugs.  Changing the SVR4 ABI implementation, even to fix a bug, is
difficult because of the problems it causes with binary compatibility
under Linux.  The EABI is intended at embedded targets and so has
fewer compatibility requirements.

I will therefore commit a patch to change BIGGEST_ALIGNMENT and a
testcase to check that the long-double structure alignment is correct.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>