This is the mail archive of the gcc@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: Altivec Linux support in GCC


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>


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