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


On 14 Apr 2003, Geoff Keating wrote:

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

What does -maltivec mean w/o -mabi=altivec?  Can I pass AltiVec arguments
to functions?  How are they passed?  What happens to the stack?  What ABI
is it using?

Why not do this the other way around.  I guess the most common situation
would be both flags.

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

Does anyone really do this on Linux?  Does this cause code linking issues
between normal LinuxPPC code and AltiVec LinuxPPC 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.
>

What situations require this?

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


I guess I would expect yet another flag to control if compiler intrinsics
should or should not use altivec.  That way the user could have as much
control as they wish.

-maltivec (enable programming model for AltiVec only, user has to use
altivec PIM to get altivec)
-mabi=altivec (enable SVR4 Altivec ABI)
-m??? (enable builtins like memcpy to use AltiVec)

- kumar





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