Hi,

On Thu, Jul 28, 2011 at 2:51 PM, Jason Garrett-Glaser <[email protected]> wrote:
> On Thu, Jul 28, 2011 at 2:50 PM, Ronald S. Bultje <[email protected]> wrote:
>> 2011/7/28 Jason Garrett-Glaser <[email protected]>:
>>> ---
>>>  libavcodec/x86/dsputil_mmx.c     |    4 +-
>>>  libavcodec/x86/h264_chromamc.asm |   44 
>>> ++++++++++++++++++-------------------
>>>  libavcodec/x86/h264_deblock.asm  |   19 +++++++--------
>>>  libavcodec/x86/h264_idct.asm     |   28 ++++++++++++------------
>>>  libavcodec/x86/x86util.asm       |    4 +-
>>>  5 files changed, 48 insertions(+), 51 deletions(-)
>>
>> Most of this looks OK.
>>
>>> -    movd          m0, [r1     ]
>>> -    punpcklbw     m0, [r1   +1]
>>> -    add           r1, r2
>>>  .next2rows
>>> -    movd          m1, [r1     ]
>>> -    movd          m3, [r1+r2  ]
>>> -    punpcklbw     m1, [r1   +1]
>>> -    punpcklbw     m3, [r1+r2+1]
>>> +    movd          m1, [r1+r2*1  ]
>>> +    movd          m3, [r1+r2*2  ]
>>> +    punpcklbw     m1, [r1+r2*1+1]
>>> +    punpcklbw     m3, [r1+r2*2+1]
>>>     lea           r1, [r1+r2*2]
>>>     movq          m2, m1
>>>     movq          m4, m3
>>
>> Something like this leaves r1 in a different state (r2 lower). That's
>> intentional right? (I assume it passes fate, I just thought it was
>> weird.)
>
> Yes, that's why I changed the addressing.
>
> The intention is to avoid the 3-clock-cycle "pointer was changed
> recently" penalty on the first iteration of the loop.

Oh right, loop label is below the add, totally missed that. Patch OK.

Ronald
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to