[FFmpeg-devel] [PATCHv2] avcodec/aac_tablegen: get rid of hardcoded tables entirely

Ganesh Ajjanagadde gajjanag at mit.edu
Sat Nov 28 16:38:39 CET 2015

On Sat, Nov 28, 2015 at 10:21 AM, Ganesh Ajjanagadde <gajjanag at mit.edu> wrote:
> On Sat, Nov 28, 2015 at 10:06 AM, Rostislav Pehlivanov
> <atomnuker at 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.

I read up some stuff and am fine with it now. Basically, some thought
made me realize that C++ would have terrible bloat issues if stuff
like this was not handled well by the toolchain - think of templates
and multiple instantiations across translation units, a very common
occurence that people (who know C++) don't complain about since they
no it is a non issue for the final executable, though they still
rightly complain about the build times.

If interested, see

More information about the ffmpeg-devel mailing list