[MPlayer-dev-eng] altivec patch 1/5: missing vec_splat in vec_clip

[Alan Curry]

Luca Barbato writes the following:
>
>Alan Curry wrote:
>
>> The advantage to the current way is that the same macro can be used with any
>> vector type whereas the long form intializer {x,x,x,x,x,x,x,x} would only be
>> good for shorts. vec_clip won't be so neatly generalized anymore. I assume
>> any such modifications should be confined within #if GCC (or a check added to
>> configure, to #define HAVE_BROKEN_VECTOR_LITERALS)
>
>wrong
>
> (cast){something} != (cast)(something)

GCC's documentation claims that it implements the AltiVec Programming
Interface Manual, with a list of exceptions. The use of braces instead of
parentheses around vector literals is one of those documented differences.
The different interpretation of a single integer in a vector literal (zero
padded instead of replicated) is not one of the documented differences. It
qualifies as at least a documentation bug. But that's not important right
now; what matters is that the different behavior has been found and mplayer
needs to deal with it somehow.

I hate to be repetitive, but the vec_splat(AVV(foo),0) construction is
already in use in several places in the same source file. Why so much
resistance to using it in vec_clip too? It's an extra instruction, and when
foo fits in 5 bits it's an extra memory reference. It's not a performance
killer.

>Next will be vec_clip_u16 vec_clip_u8 etc...

Sounds good. vec_clip_s16 is the only one that would actually be used right
now anyway.