altivec support in gcc

[Aldy Hernandez]

>>>>> "Michel" == Michel LESPINASSE <walken@zoy.org> writes:

 > Hi,
 > I have a few questions about the altivec support in gcc...

 > First, is there any reason why altivec.h defines the second argument
 > in vec_ld as being a vector pointer instead of a const vector pointer ?
 > This is causing me no ends of trouble.

Why is this causing you trouble?

 > Second, I have not tried gcc 3.3 yet, but gcc 3.2 has a lot of trouble
 > compiling the following construct... it does compile it eventually,
 > but it requires hundreds of megabytes of virtual memory for doing
 > it...

 > (This code is meant as a shortcut for calculating (A+B+C+D+2)>>2, for
 > a vector of 16 unsigned char values. This is used in the motion
 > compensation loop of an mpeg2 decoder.)

 >     ones = vec_splat_u8 (1);
 >     avg0 = vec_avg (A, B);
 >     xor0 = vec_xor (A, B);
 >     avg1 = vec_avg (C, D);
 >     xor1 = vec_xor (C, D);
 >     tmp = vec_and (vec_and (ones, vec_or (xor0, xor1)),
 >                    vec_xor (avg0, avg1));
 >     out = vec_sub (vec_avg (avg0, avg1), tmp);

You need to split the last two assignments as you have discovered.  If
you want to see why, compile with -save-temps and look at the
preprocessed output (the .i file).

All the altivec functions in C get expanded into a disgusting set of
macros.  These macros expand exponentially when you use them to call
themselves.  This is not likely to change until the C front end has
overloaded functions, and we have no need for the macros.

If you want something that compiles in less than infinity minus 1 for
these constructs, I recommend you use C++.

Aldy