On Thu, Jan 24, 2019 at 10:23:33PM +0100, Marton Balint wrote: > > > On Sun, 20 Jan 2019, Michael Niedermayer wrote: > > >On Sun, Jan 20, 2019 at 07:35:18PM +0100, Marton Balint wrote: > >> > >> > >>On Sun, 20 Jan 2019, Michael Niedermayer wrote: > >> > >>>On Sat, Jan 19, 2019 at 11:48:39PM +0100, Marton Balint wrote: > >>>>Signed-off-by: Marton Balint <c...@passwd.hu> > >>>>--- > >>>>libavcodec/motion_est.c | 4 +-- > >>>>libavcodec/motion_est_template.c | 62 > >>>>+--------------------------------------- > >>>>2 files changed, 3 insertions(+), 63 deletions(-) > >>> > >>>please check if the compiler optimizes the size constant out after this > >>>change > >> > >>The compiler inlines the function before and after the change as well. I > >>can't see notable changes in the disassembly of interlaced_search and > >>h263_mv4_search. Is this enough, or something else should be checked? I am > >>not sure how... > > > >If the inlined code is used with only one size value then its probably ok. > >you could also put some marker with asm() in the code where size is used > >and then look at the .s file generated if the size is optimized out or > >still read as a variable > > I checked the .s file and a constant is pushed to the stack as the size > parameter when funny_diamond_search is called in h263_mv4_search and > interlaced_search. > > So yes, the size parameter is still optimized as a constant in the touched > functions.
i guess its ok then thanks for checking [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel