Hi, On Fri, Jan 15, 2016 at 4:47 PM, James Darnley <james.darn...@gmail.com> wrote:
> On 2016-01-15 21:55, James Almer wrote: > > 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. > > I don't understand how that works then. It calls the cglobal macro. > Does that not just assume missing args are 0? I'd better look and > follow that more closely. Yes, it uses %ifnum on %4. If it's a number, it takes it as stack mem, else it takes it as name of first function argument. Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
