Re: contributing altivec changes

[Aldy Hernandez <aldyh at redhat dot com>]

> The alignment macros definitely need to change.

yes, on my todo.  prob tommorrow.

> > Likewise, this changes the ABI, so must be ABI-dependent.  You can't
> > add new call-saved registers to an ABI.

i am going to add -mabi=altivec-sysv and -mabi=altivec-eabi

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

yes, thank you for pointing this out.  the reason v2 was different was
*because* the bits were backwards and i hadn't noticed-- and return
values were not working because gcc thought it was call clobbered. oops.

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

pretty much the same as mine.

> I haven't looked carefully at the builtin stuff (which is very different
> from Moto's) or the new patterns.

stan told me moto/apple patches didn't have builtins... and that the
original moto patches has a vector mode analogous to the BLKmode (as
opposed to V4SI, V8HI, etc.

> 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

it's actually working already, but i haven't done any serious testing
because i just got the g3 box this week.  besides, i really need that
vrsave and alignment stuff implemented before i try anything serious--
especially on actual hardware.

also-- i need to code some pretty intense tests and i just haven't had
the time.  there are LOTS of builtins.

code like the following already works:

    typedef int __v4si __attribute__ ((mode(V4SI)));
    typedef int __v8hi __attribute__ ((mode(V8HI)));
    
    int   array1[4] __attribute__((aligned(16))) = { 10000, 10000, 10000, 10000 };
    int   array2[4] __attribute__((aligned(16))) = { 10000, 10000, 10000, 10000 };
    
    __v4sf a, b, c, d;
    __v8hi e;
    __v4si i,j,k;
    
    
    foo ()
    { 
            i = __builtin_altivec_ld_internal (array1);
            j = __builtin_altivec_ld_internal (array2);
            k = __builtin_altivec_vadduws (i, j);
    	e = (__v8hi) k;
    }

i will repost tommorrow after fixing up the suggestions geoff pointed
out (and implementing alignment, etc).

-- 
Aldy Hernandez			E-mail: aldyh@redhat.com
Professional Gypsy
Red Hat, Inc.