[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