On Sat, Nov 28, 2015 at 10:06 AM, Rostislav Pehlivanov <atomnu...@gmail.com> wrote: > On Sat, 2015-11-28 at 09:45 -0500, Ganesh Ajjanagadde wrote: >> >> Removed the av_cold, did not find a way to cleanly get rid of the >> inline. I do suggest giving it some thought; it is needless >> executable >> bloat since the inline does not help perf. Pushed, thanks. >> > Hardly a blot as it's really only used twice in the entire code and the > function isn't a particularly big one.
I was concerned since the generated tables are not huge; we do not want to bloat the binary size with redundant code, else one may be better off with hardcoded tables. > Moreover even if it was a big > function used in a few more places GCC can and will magically uninline > it Did not know that. I am somewhat skeptical - aacdec, aacenc (the two usages) are compiled separately, so the compiler may lack this information. At link time, in principle while stitching things together, the duplication can be removed. But this will likely happen on LTO only builds. LTO is currently very buggy - if auto-vectorization itself is problematic in general for FFmpeg, LTO should not be touched by any means for release builds. If both usages were in the same file, I agree with you. > (which is why I'm not really a fan of using av_always_inline for > every single function which has to be inlined, better to let the > compiler figure it out and if it can't it'll just inline it anyway). Agreed. > But I digress, the whole point of inlining this particlar function was > so it could be put inside the header and not inside aactab.c (which > contains no executable code at all). yes, this is why there is no clean solution, including aactab.h in aactab.c causes failures. > _______________________________________________ > 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
