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