This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: AltiVec stack boundary
- From: Daniel Jacobowitz <drow at false dot org>
- To: Geoffrey Keating <geoffk at apple dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Sat, 29 Sep 2007 11:23:27 -0400
- Subject: Re: AltiVec stack boundary
- References: <20070807143936.GA1603@caradoc.them.org> <m2y7eqtj5a.fsf@greed.local>
On Fri, Sep 28, 2007 at 05:22:41PM -0700, Geoffrey Keating wrote:
> The case where this matters is a 32-bit ELF EABI target (the only case
> on powerpc that allows 8-byte stack alignment) using -maltivec but not
> -mabi=no-altivec. It's not clear to me that case works.
I was originally worried about powerpc-linux. I think I was fooled by
the STACK_BOUNDARY definition, though. If the ABI actually mandates
16-byte alignment and GCC rounds up the size of stack frames it
generates, then things will work out (barring broken startup code).
So you must be right - it's just powerpc-eabi.
> I don't think that in general you want to do this in an embedded
> context, because of the extra code generated to align the stack; it'd
> be much better to just declare that you're going to use the AltiVec
> ABI, even if some parts of your embedded code won't be allowed to use
> any AltiVec instructions.
Well, it would be nice if it worked - since e.g. the GCC testsuite
will try to use it! However, this doesn't affect me directly; I
test the standard powerpc-linux ABI on AltiVec capable hardware,
but I only test -mabi=altivec on our AltiVec capable EABI targets.
Thanks.
--
Daniel Jacobowitz
CodeSourcery