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

[Ganesh Ajjanagadde]

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.

> (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 at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel