[FFmpeg-cvslog] r24926 - trunk/libavcodec/x86/vp56dsp.asm

Reimar Döffinger Reimar.Doeffinger
Thu Aug 26 23:22:52 CEST 2010


On Thu, Aug 26, 2010 at 10:01:23PM +0100, M?ns Rullg?rd wrote:
> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> > On Thu, Aug 26, 2010 at 09:27:55PM +0100, M?ns Rullg?rd wrote:
> >> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> >> > But in case I was unclear, I actually managed to construct
> >> > a case (of course very artificial) that shows the issue
> >> > _in principle_ even with non-broken/ancient compilers.
> >> >
> >> > extern long j;
> >> > extern char *array;
> >> > int test(void)
> >> > {
> >> >   int i;
> >> >   int s;
> >> >   for (i = 0; i < j; i++)
> >> >       s += array[i];
> >> >   return s;
> >> > }
> >> > int test2(void)
> >> > {
> >> >   unsigned i;
> >> >   int s;
> >> >   for (i = 0; i < j; i++)
> >> >       s += array[i];
> >> >   return s;
> >> > }
> >> > int test3(void)
> >> > {
> >> >   unsigned long i;
> >> >   int s;
> >> >   for (i = 0; i < j; i++)
> >> >       s += array[i];
> >> >   return s;
> >> > }
> >> >
> >> > Compiled on PowerPC 64 the three loops are:
> >> > .L3:
> >> >         lbzx 0,9,11
> >> >         addi 11,11,1
> >> >         add 0,0,3
> >> >         extsw 3,0
> >> >         bdnz .L3
> >> >
> >> > .L9:
> >> >         lbzx 9,10,11
> >> >         addi 0,11,1
> >> >         rldicl 11,0,0,32
> >> >         add 9,9,3
> >> >         cmpd 7,11,8
> >> >         extsw 3,9
> >> >         blt 7,.L9
> >> >
> >> > .L14:
> >> >         lbzx 0,9,11
> >> >         addi 11,11,1
> >> >         add 0,0,3
> >> >         extsw 3,0
> >> >         bdnz .L14
> >> 
> >> Yes, the compiler did badly with the 32-bit unsigned counter.  What
> >> is that supposed to prove?
> >
> > That it seems like PPC64 also does not have a 32x32->32 addition
> 
> It doesn't have _unsigned_ 32-bit addition.

Does it have a signed one? I assumed it just relied on signed
overflow being undefined or something like that for the int case...

> > and just like for x86 a register-size type is the easiest way
> > to tell the compiler that no, we really don't care about the
> 
> No, the signed 32-bit and unsigned 64-bit gave exactly the same code.
> Why do you call one of them easier?

Well, at the very least the int version doesn't
work if the array is actually 2 GB or larger.
Not so likely, however that also applies to other
adds where it's more likely we need bit 31.



More information about the ffmpeg-cvslog mailing list