[FFmpeg-devel] MPEG-2 Acceleration Refactor

[Måns Rullgård]

Michael Niedermayer <michaelni at gmx.at> writes:

> if yes then this is a new gcc bug, that is gcc inlines fewer functions
> with av_always_inline but there is not a single function it inlines in the
> av_always_inline case which wasnt already inlined wthout it

I'm not surprised by this.  By forcing inlining of some functions that
were not automatically inlined, and thus probably quite large, the
size of the calling function increases.  Since the automatic inlining
depends on the resulting size of the calling function, fewer
automatically inlined functions are not so strange.  Try adding
-finline-limit=some-large-number and see if anything changes.

> if no and the normal inline case looks different then this is still a
> gcc bug just not a new one, av_always_inline should IMO inline the function
> without changing the inlining of the other code (if av_inline behaves
> different, which it does sadly, then its not usefull for anything and
> another attribute which does force the inlining of a function without
> code slowification sideeffectes would be needed)
>
> maybe you should complain to the gcc devels to either fix always inline
> or provide a attribute which really inlines a function without sideeffects

The inline keyword is nothing but a hint to the compiler that the
function might benefit from being inlined.  The compiler is free to
ignore it or to inline functions without it.  The final choice is
(ideally) that which makes the calling function faster.  Now if some
other function is forcibly inlined, the effect of inlining other
functions can quite reasonably be expected to change, just like had
more code been added to function body itself.  Expecting the decisions
whether to inline other function calls to be unaffected by this
addition of code doesn't seem quite rational to me.

I'm quite prepared to believe that gcc is making bad decisions, but
that's another aspect.  The fix in that case is to tune the process of
deciding what to inline.  In part, this can be done by supplying
compiler flags like -finline-limit and other more fine-grained ones.
Estimating the effects on speed from function inlining is not at all
trivial, so we shouldn't be too hard on the gcc devs, at least not
until we've asked them about it.

-- 
M?ns Rullg?rd
mans at mansr.com