Re: Vector Extensions in GCC

[Daniel Berlin <dan at cgsoftware dot com>]

Stan Shebs <shebs@apple.com> writes:

> Daniel Berlin wrote:
>> 
>> > Intel's
>> > docs are pretty sketchy on all this, mostly focused on a mysterious
>> > builtin __m128 type of indeterminate nature, and not present in GCC.
>> 
>> Actually, it's just defined as
>> 
>> typedef int __m128 __attribute__ ((mode (TI)));
>> typedef int __v4sf __attribute__ ((mode (V4SF)));
>> typedef int __v4si __attribute__ ((mode (V4SI)));
> 
> OK, that demystifies a lot.
> 
>> It's in a file that gcc doesn't have, nobody every bothered to submit
>> it (xmmintrin.h).
> 
> Seems like it would be a good idea to have in, eh?
It's not well taken care of.
It had a missing paren  on an important macro that i noticed and
fixed, so i get the feeling it wasn't really used much internally (i'm sure the
customer fixed the same bug, and just never reported it).

>   Several people
> have asked about it over the past several months, this is the
> first concrete reply I've seen.  Even better, we should have test
> cases, leaves no room for confusion about whether the support works.

> 

I agree.

>> > 0. Basic vector register support.  Names, classes etc.
>> 
>> We have this.
> 
> I was referring to the AltiVec-specific bits that will need to go
> into config/rs6000.
Oh, oh.
I thought you meant in generic code.
My bad.

> 
>> I'm a ppc linux folk, and i've never used the vector extensions.
> 
> Obviously I'm referring to GCC users who do signal processing,
> graphics, and all those other applications.  There are a bunch of
> people who buy PowerMacs specifically to install Linux and run
> hand-vectorized code on them.
Oh, wasn't aware that these people existed.
Seriously.
:)

> 
> Stan

-- 
"One night I walked home very late and fell asleep in somebody's
satellite dish.  My dreams showed up on TVs all over the world.
"-Steven Wright