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


> Date: Fri, 30 Apr 2004 18:12:06 -0400
> From: David Edelsohn <dje@watson.ibm.com>

> >>>>> 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.

I agree, but the correct behaviour if the alignment can't be achieved is
to warn about the user's incompatible choice of options, not silently
generate code that assumes an alignment greater than actually exists.

> 	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. 

I think they are not sufficient.  I believe that GCC does not have
full support for creating a stack alignment greater than the
pre-existing one in the procedure prolog.  It might actually not be
that hard to make the prolog/epilog code do it, but I don't think it'd
be that useful, since the only case where this is necessary is for
'-meabi -maltivec -mabi=no-altivec' and I don't think anyone actually
uses this intentionally.

SVR4 has historically actually had 128-bit alignment, the 64-bit
STACK_BOUNDARY was for compatibility with EABI code, as the comment
says:

/* Alignment in bits of the stack boundary.  Note, in order to allow building
   one set of libraries with -mno-eabi instead of eabi libraries and non-eabi
   versions, just use 64 as the stack boundary.  */
#undef  STACK_BOUNDARY
#define STACK_BOUNDARY  (TARGET_ALTIVEC_ABI ? 128 : 64)

Now, you may want to change this to be the same as:

/* Real stack boundary as mandated by the appropriate ABI.  */
#define ABI_STACK_BOUNDARY ((TARGET_EABI && !TARGET_ALTIVEC_ABI) ? 64 : 128)

so that you can use -maltivec without using the Altivec ABI; but then
you'll lose the convenience of one fewer multilib multiplier.  This
would probably be acceptable.

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


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