[MPlayer-dev-eng] altivec patch 1/5: missing vec_splat in vec_clip
Alan Curry
pacman at theworld.com
Tue Feb 7 23:43:22 CET 2006
Luca Barbato writes the following:
>
>Alan Curry wrote:
>> vec_clip() is the only thing that uses AVV() with a single non-zero argument
>> and doesn't use vec_splat(). There's a good reason the others all surround it
>> in vec_splat(...,0). AVV(235) is {235,0,0,0,...} at least on some compilers.
>>
>
>Maybe you could check if the code produced using splats+hopefully loade
>element or using direct load is better or worse.
Well, without the splat it produces incorrect results, which is definitely
worse.
The splatted constant doesn't get optimized as well as we might hope. (It
puts the {x,0,0,0,...} in memory and does a load and a splat at runtime.) If
we want it optimized, it looks like we need to be writing them all out the
long way:
(vector signed short)AVV(16,16,16,16,16,16,16,16)
instead of the less efficient
vec_splat(((vector signed short)AVV(16,16,16,16,16,16,16,16)),0)
or the correct-but-miscompiled-by-gcc3
(vector signed short)AVV(16)
If writing them all out the long way is acceptable, I'll change it and test
it and diff it again. I only chose the vec_splat because that's what was
already in use, throughout the rest of that same source file. It's a minimal
change to get things working and looking consistent.
Anyone with gcc-4.x want to find out if this has been fixed?
gcc -maltivec -abi=altivec this:
#include <stdio.h>
#include <altivec.h>
int main(void)
{
vector signed int x=(vector signed int){1};
vector signed int y=(vector signed int){1,1,1,1};
if(!vec_all_eq(x,y)) {
printf("Broken! x={%d,%d,%d,%d} y={%d,%d,%d,%d}\n",
((int *)&x)[0], ((int *)&x)[1], ((int *)&x)[2], ((int *)&x)[3],
((int *)&y)[0], ((int *)&y)[1], ((int *)&y)[2], ((int *)&y)[3]);
} else {
printf("OK\n");
}
}
More information about the MPlayer-dev-eng
mailing list