Re: altivec support in gcc

[Michel LESPINASSE <walken at zoy dot org>]

Hi Aldy,

On Wed, Apr 09, 2003 at 09:15:42AM -0700, Aldy Hernandez wrote:
>  > 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?

Well, this is nothing that I could not work around, but if I passed a
const vector pointer gcc would complain that vec_ld discards the const
modifier (dont remember the exact wording, but its the message you get
when you pass a const pointer to a function that just takes a regular
pointer, and gcc warns that function might write into your supposedly
const data). In the context of vec_ld, the warning is stupid since
vec_ld does NOT write into the data, and gcc should know it I think.

Anyway - I had to add an explicit cast for the second argument of each
vec_ld, just to keep gcc happy. In that regard, gnu gcc is not
compatible with the old apple altivec-patched gcc. In the end, because
I did not want to change all my vec_ld calls, I defined a my_vec_ld
function with the cast, and then I used the preprocessor to replace
all the vec_ld's with my_vec_ld. Like this:

static inline vector_u8_t my_vec_ld (int const A, const uint8_t * const B)
{
    return vec_ld (A, (uint8_t *)B);
}
#undef vec_ld
#define vec_ld my_vec_ld

This is ugly but it solved my problem :) I understand you can not do
this in altivec.h though, because my version is limited by the fact it
will only work on unsigned char vectors.

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

Yes. I looked at altivec.h and I understood what the issue is - it has
to do all these weird convolutions to emulate function overloading,
and as each argument gets expanded more than once this leads to
exponential explosion.

Still from a user point of view, this does look a bit silly - I can
write expressions like out = a & b & c & d; and this works with any
mix of integer types for a, b, c and d, and thanks god I don't have to
split up a small expression like that - the compiler just figures it
out. As a user, I would expect to be able to do the same things with
vector types. Trying to understand what the difference is from gcc's
point of view, I see that '&' is an operator, while vec_and internally
relies on a builtin function, and that builtin functions are more
limited as they dont support overloading, while C operators do. I dont
know if it would be possible to somehow make gcc know about new
operators for altivec ? that way vec_and(a,b) could be defined as
something like ((a) __altivec_operator_and (b)) and
__altivec_operator_and would be some operator, similar to &, which can
take various types as input. I'm probably talking way out of my league
here though.

Once again, I used functions and preprocessor tricks to get rid of the
exponential explosion issue, by taking advantage of the fact I only
needed unsigned char vector versions of vec_and and vec_avg:

#ifndef COFFEE_BREAK    /* Workarounds for gcc suckage */

static inline vector_u8_t my_vec_and (vector_u8_t const A, vector_u8_t const B)
{
    return vec_and (A, B);
}
#undef vec_and
#define vec_and my_vec_and

static inline vector_u8_t my_vec_avg (vector_u8_t const A, vector_u8_t const B)
{
    return vec_avg (A, B);
}
#undef vec_avg
#define vec_avg my_vec_avg

#endif

This is ugly but it does the trick for me - and frankly I did not want
to break up all my expressions using temporaries if that makes them
unreadable.

I'm not sure what a good solution would be here. For starters, if
altivec.h exported some non-overloaded versions of these functions,
that might help a little - for example vec_and would be the overloaded
version and vec_and_u8, vec_and_u16, vec_and_float, ... would be the
non overloaded versions... I'm not sure if its doable as apple's
altivec spec does not define these non overloaded versions though.

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

hmmm is there actually any plan for implementing overloaded functions
in the C front end ?

Not that I'd push for this thing (I dont think we want to make C look
too much like C++) but it might be useful, at least for builtins, so
gcc can better support the altivec intrinsics and stuff.

Thanks,

-- 
Michel "Walken" LESPINASSE
"In this time of war against Osama bin Laden and the oppressive
Taliban regime, we are thankful that OUR leader isn't the spoiled son
of a powerful politician from a wealthy oil family who is supported by
religious fundamentalists, operates through clandestine organizations,
has no respect for the democratic electoral process, bombs innocents,
and uses war to deny people their civil liberties." --The Boondocks