[FFmpeg-cvslog] r23391 - trunk/libavcodec/ivi_common.c

[Måns Rullgård]

Maxim <max_pole at gmx.de> writes:

> M?ns Rullg?rd schrieb:
>> Maxim <max_pole at gmx.de> writes:
>>
>>   
>>> M?ns Rullg?rd schrieb:
>>>     
>>>> maxim <subversion at mplayerhq.hu> writes:
>>>>
>>>>   
>>>>       
>>>>> Author: maxim
>>>>> Date: Mon May 31 01:57:51 2010
>>>>> New Revision: 23391
>>>>>
>>>>> Log:
>>>>> Make dequantization equation use less registers on some CPUs.
>>>>>
>>>>> Modified:
>>>>>    trunk/libavcodec/ivi_common.c
>>>>>
>>>>> Modified: trunk/libavcodec/ivi_common.c
>>>>> ==============================================================================
>>>>> --- trunk/libavcodec/ivi_common.c	Mon May 31 00:25:40 2010	(r23390)
>>>>> +++ trunk/libavcodec/ivi_common.c	Mon May 31 01:57:51 2010	(r23391)
>>>>> @@ -416,7 +416,7 @@ int ff_ivi_decode_blocks(GetBitContext *
>>>>>
>>>>>                      q = (base_tab[pos] * scale_tab[quant]) >> 8;
>>>>>                      if (q > 1)
>>>>> -                        val = val * q + FFSIGN(val) * ((q >> 1) - (q & 1));
>>>>> +                        val = val * q + FFSIGN(val) * (((q ^ 1) - 1) >> 1);
>>>>>     
>>>>>         
>>>> What about the CPUs where this sequence is slower?
>>>>   
>>>>       
>>> Which CPU(s) do you mean? On both x86 and PowerPC it should work fine...
>>>     
>>
>> ARM.  The old code can be done like this:
>>
>>   and  r0, r1, #1
>>   rsb  r0, r0, r1, lsr #1
>>
>> The new code needs three instructions:
>>
>>   eor  r0, r1, #1
>>   sub  r0, r0, #1
>>   lsr  r0, r0, #1
>>
>> Assuming, of course, the compiler doesn't do this transformation.
>>   
>
> What do you suggest to do? Introduce a switch like:
>
> #if /ARCH_ARM
> /* do it the old way */
> #else
> /* do it the new way*/

No, of course not.

> /I personally don't care about such "+/- one instruction"-optimizations
> (to be sincerely) because noone is able to notice any performance
> difference in this case. Fix me if I'm wrong...

Unless there's a measurable performance difference, it doesn't matter.

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