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

[Måns Rullgård]

Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:

> On Thu, Aug 26, 2010 at 08:39:25PM +0100, M?ns Rullg?rd wrote:
>> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
>> > On Thu, Aug 26, 2010 at 03:25:52PM -0400, Ronald S. Bultje wrote:
>> >> On Thu, Aug 26, 2010 at 3:10 PM, Reimar D?ffinger
>> >> <Reimar.Doeffinger at gmx.de> wrote:
>> >> > I complained about the name back then already, but x86_reg is designed
>> >> > to and can be used just fine on all architectures, there really
>> >> > is no need to reinvent the wheel.
>> >> > If the term "x86" alone makes you run away screaming then the
>> >> > solution is to rename it and move it out of x86_cpu.h, but
>> >> > you certainly don't need to reinvent it!
>> >> 
>> >> Got it, the name confused me. I'm OK with it then, if Mans is OK also
>> >> (even though the problem is limited to x86 only, apparently).
>> >
>> > This specific problem? Yes.
>> > The problem in general? Not so sure.
>> > Nowadays compilers tend to be brighter, but one of the issues tended to be that
>> > something like
>> > int i;
>> > for (i = 0; i < j; i++)
>> >    array[i];
>> > ended up with a sign-extension inside the loop.
>> > I'd think that is not that unlikely to apply to other 64 bit 
>> > architectures as well and would make a "register-size" type
>> > useful for them as well.
>> 
>> That problem is also specific to x86.  I know of no other architecture
>> where the declared type of the counter would make a difference in a
>> construct like that.
>
> I'd appreciate it if you could give me the impression
> of at least trying to understand me instead of just
> finding a way to bash x86.

Well, I'm sorry if x86 is more of a botch job than just about any
other architecture around.  Do you want me to imagine insane quirks in
the others too just to make it more fair?

> 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 a badly with the 32-bit unsigned counter.  What
is that supposed to prove?

-- 
M?ns Rullg?rd
mans at mansr.com