This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: rs6000 stack boundary

From: David Edelsohn <dje at watson dot ibm dot com>
To: Geoff Keating <geoffk at geoffk dot org>
Cc: Alan Modra <amodra at bigpond dot net dot au>, gcc-patches at gcc dot gnu dot org
Date: Fri, 30 Apr 2004 18:12:06 -0400
Subject: Re: rs6000 stack boundary
References: <20040430143702.GO2565@bubble.modra.org> <jm65bhxh7l.fsf@desire.geoffk.org>

>>>>> Geoff Keating writes:

Geoff> This isn't right; it's not true that all ELF targets have a 128-bit
Geoff> stack boundary.  In particular, EABI targets don't.  Remember,
Geoff> TARGET_ALTIVEC does not change ABI.  The change would be OK if it
Geoff> didn't have the TARGET_ALTIVEC part.  (Note that the sysv4.h
Geoff> definition of STACK_BOUNDARY was correct.)

	TARGET_ALTIVEC cannot work without some form of stricter
alignment.  It is fine to separate the ABI in theory, but the alignment
requirements and truncated displacements of Altivec instructions forces
stricter alignment for Altivec variables.

	Are STARTING_FRAME_OFFSET and STACK_DYNAMIC_OFFSET sufficient?
Remember that Darwin has enforced a stricter alignment for all
applications and something similar is needed for SVR4 when Altivec is
enabled. 

David

Follow-Ups:
- Re: rs6000 stack boundary
  - From: Geoff Keating

References:
- rs6000 stack boundary
  - From: Alan Modra
- Re: rs6000 stack boundary
  - From: Geoff Keating

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]