[FFmpeg-devel] MPEG-2 Acceleration Refactor

Trent Piepho xyzzy
Fri Jun 22 20:53:45 CEST 2007


On Fri, 22 Jun 2007, Michael Niedermayer wrote:
> as said read the thread (again?), the case is:
> big_function2(){
>     for(){
>         tiny_speed_critical_function()
>     }
> }
>
> big_function3(){
>     for(){
>         tiny_speed_critical_function()
>     }
> }
>
> big_function1(){
>     for(){
>         if(X)
>             big_function2();
>         else
>             big_function3();
>     }
>     for(){
>         tiny_speed_critical_function()
>     }
> }
>
> and gcc inlines everything by default but when
> the very similar big_function2 and big_function3 get merged, thus the
> code looks like:
>
> always_inline big_function23(X){
>     for(){
>         tiny_speed_critical_function()
>     }
> }
>
> big_function1(){
>     for(){
>         if(X)
>             big_function23(1);
>         else
>             big_function23(0);
>     }
>     for(){
>         tiny_speed_critical_function()
>     }
> }
>
> gcc does not inline tiny_speed_critical_function() anymore !!!!
> it does inline big_function23()

This might have something to do with the parameter large-function-growth.
gcc limits the amount of inlining it will do _into_ big_function1() if that
function has grown to more than twice its size without inlining.  It seems
like gcc is obeying the always_inline attribute.

Anyway, I would do this a little differently:

always_inline big_function23(X)
{ ... }

big_function2()
{
    big_function23(1);
}

big_function3()
{
    big_function23(0);
}

Now big_function2() is identical to what you would have if you took
big_function23 and made X a constant 1, and same with big_function3 and X a
constant 0.




More information about the ffmpeg-devel mailing list