On Thu, Jul 28, 2011 at 2:54 PM, Ronald S. Bultje <[email protected]> wrote: > 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
Applied. Jason _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
