This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Altivec Linux support in GCC
- From: Geoff Keating <geoffk at geoffk dot org>
- To: Kumar Gala <kumar dot gala at motorola dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: 14 Apr 2003 12:40:55 -0700
- Subject: Re: Altivec Linux support in GCC
- References: <7C4FF3D4-6EA1-11D7-A551-000393DBC2E8@motorola.com>
Kumar Gala <kumar dot gala at motorola dot com> writes:
> I have a few questions that I'm trying to understand with AltiVec
> support in GCC for Linux.
>
> 1. What are there two options to enable the support? (-maltivec
> -mabi=altivec).
They enable different parts of the support.
> If I have a Linux PPC targeted GCC why do I need to
> tell it to use the abi to get altivec code generation?
You don't; if you just want altivec code, you can use just -maltivec.
However, this doesn't get you the Altivec ABI.
> This just seems confusing to the user (I dont have to specify the
> abi for any other option).
The only option that specifies both instruction set and ABI is
-msoft-float, and it should really be two options, one which disables
all the FP arithmetic instructions and one which changes the ABI. It
would be useful on chips without a FPU to be able to avoid generating
FP arithmetic but still be able to interface with SVR4 code.
> 2. Why does STACK_BOUNDARY change for TARGET_ALTIVEC_ABI? The stack
> alignment is the same with or without AltiVec according the SVR4 PPC
> ABI.
STACK_BOUNDARY is set to 8 bytes by default, to permit linking EABI
code with SVR4 code.
Please be sure you know what STACK_BOUNDARY controls. The stack is
still kept 16-byte aligned (or to be precise, is allocated in 16-byte
chunks) even when STACK_BOUNDARY is 8.
> It seems that a single GCC targeted for PowerPC Linux should be able
> to support generation for int+fp+altivec, and if you dont use altivec
> in your code you dont get altivec generated by the compiler [ie you
> get the same .S out you would today, w/o enabling -maltivec
> -mabi=altivec].
This is technically impossible due to the differences between the
Altivec ABI and the SVR4 ABI; some situations require saving all the
call-saved registers, and that list differs between the two ABIs.
It sounds this is the Altivec equivalent of the request "if my program
uses no FP operations, I don't want any FP instructions generated".
This has been much discussed on this list, but as yet no-one has
implemented it. As a default, it's in conflict with good optimisation
practises (like using Altivec for structure copies).
--
- Geoffrey Keating <geoffk at geoffk dot org>