This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: contributing altivec changes
- To: Geoff Keating <geoffk at redhat dot com>
- Subject: Re: contributing altivec changes
- From: Dale Johannesen <dalej at apple dot com>
- Date: Wed, 31 Oct 2001 15:30:11 -0800
- Cc: Dale Johannesen <dalej at apple dot com>, aldyh at redhat dot com, gcc-patches at gcc dot gnu dot org
I previously replied to this message too soon; please ignore.
On Wednesday, October 31, 2001, at 01:01 PM, Geoff Keating wrote:
>> From: Aldy Hernandez <aldyh@redhat.com>
> Shouldn't there be changes to the various alignment macros? Altivec
> operands _must_ be 128-bit aligned, or they won't work, that means the
> stack must also be 128-bit aligned.
The alignment macros definitely need to change.
>> *************** extern int rs6000_debug_arg; /* debug a
>> *** 669,675 ****
>> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
>> 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, \
>> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
>> ! 1, 1, 1, 1, 1, 1, 0, 0, 0, 1, 1, 1, 1}
>>
>> #define MQ_REGNO 64
>> #define CR0_REGNO 68
>> --- 680,690 ----
>> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
>> 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, \
>> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
>> ! 1, 1, 1, 1, 1, 1, 0, 0, 0, 1, 1, 1, 1, \
>> ! /* AltiVec registers. */ \
>> ! 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, \
>> ! 0, 0, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1 \
>> ! }
>
> Likewise, this changes the ABI, so must be ABI-dependent. You can't
> add new call-saved registers to an ABI.
Besides, I think the bits are backwards; this is registers clobbered
by the call, not preserved by it. And I see no need to treat V2
differently from V0.
>> + AltiVec registers:
>> + v0 - v1 (not saved or used for anything)
>> + v13 - v3 (not saved; incoming vector arg registers)
>> + v2 (not saved; incoming vector arg reg; return value)
>> + v19 - v14 (not saved or used for anything)
>> + v31 - v20 (saved; order given to save least number)
>> + */
Hmm. For comparison purposes, here is the corresponding comment in
the Motorola/Apple version:
v0 - v1 (not saved or used for anything)
v13 - v3 (not saved; incoming vector arg registers)
v2 (not saved; return value)
v19 - v14 (not saved or used for anything)
v31 - v20 (saved; order given to save least number)
Doesn't matter to me, but if you're going to be paranoid...
I haven't looked carefully at the builtin stuff (which is very different
from Moto's) or the new patterns.
How close are you to having this work? I'm inclined to defer accepting
any of it until it works; there are probably bugs that aren't obvious from
reading, but will show up once you start testing.