This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: altivec support in gcc
- From: Aldy Hernandez <aldyh at redhat dot com>
- To: Michel LESPINASSE <walken at zoy dot org>
- Cc: gcc at gcc dot gnu dot org
- Date: 09 Apr 2003 09:15:42 -0700
- Subject: Re: altivec support in gcc
- References: <20030408085330.GC20370@zoy.org>
>>>>> "Michel" == Michel LESPINASSE <walken at zoy dot 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