On 1/15/2016 5:00 PM, James Darnley wrote: > On 2016-01-15 03:55, James Almer wrote: >> On 1/14/2016 11:05 PM, James Darnley wrote: >>> diff --git a/libavcodec/x86/h264_deblock.asm >>> b/libavcodec/x86/h264_deblock.asm >>> index 5151f3c..20f0814 100644 >>> --- a/libavcodec/x86/h264_deblock.asm >>> +++ b/libavcodec/x86/h264_deblock.asm >>> @@ -864,7 +864,47 @@ ff_chroma_inter_body_mmxext: >>> DEBLOCK_P0_Q0 >>> ret >>> >>> +cglobal h264_h_loop_filter_chroma422_8, 5, 7, 8, mmsize + >>> ARCH_X86_64*2*mmsize >> >> This will not work with x86_32 compilers that don't have aligned stack (Like >> msvc) >> because r6 is needed to store the stack pointer. > > The other chroma deblock function I borrowed most of this from doesn't > appear to use any guard against that (see a few lines above where my > patch starts). Neither in assembly or in the init function.
That's because the other chroma function doesn't allocate stack using x86inc magic. On x86_32 it uses r#m only and on x86_64 it handles the stack pointer by itself. > >>> + %if ARCH_X86_64 >>> + %define buf0 [rsp+16] >>> + %define buf1 [rsp+8] >>> + %else >>> + %define buf0 r0m >>> + %define buf1 r2m >>> + %endif >>> + >>> + movd m6, [r4] >> >> Since r4 is free after this point, you can use it instead of r6 to easily >> solve >> the above. > > Noted. > > > > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel