[FFmpeg-devel] MPEG-2 Acceleration Refactor

[Michael Niedermayer]

Hi

On Fri, Jun 22, 2007 at 09:54:06AM +0100, Michael Donaghy wrote:
> On Friday 22 June 2007 09:24:49 Michael Niedermayer wrote:
> > Hi
> >
> > On Fri, Jun 22, 2007 at 09:08:23AM +0100, M?ns Rullg?rd wrote:
> > [...]
> >
> > > > 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.
> >
> > it does seem quite rational to me
> > i want a attribute which behaves as if i copy and pasted the code or
> > replaced it by a macro but without the source code duplication of the
> > first and uglyness of \ at the end of each line of the second case
> 
> But that's what av_always_inline is doing! 

no it is not, go and read this thread again, especially the nm output


> Are you going to seriously claim 
> that replacing a function call with a copy/paste or macro would *not* change 
> whether other functions were inlined?
> Say you have
> function1(a, b){
> return function2(b, a);
> }
> where function2 is big.
> If function2 hasn't been inlined, gcc will probably automatically inline 
> function1. If function2 is has been forcibly inlined, then gcc may well not 
> inline function1. This is the correct behaviour, and is the same as what 
> would happen if you replaced function2 with a macro or copy/paste.

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()

and without always_inline it does inline both big_function23 and
tiny_speed_critical_function
this behavior is inconsistent and very wrong in the always_inline
case


> >
> > well i dont disagree that by finetuning various gcc flags and extensively
> > benchmarking the affected code (we dont want to have per file
> > -finline-limit i guess, so this could be alot of cases to benchmark ...) we
> > likely can improve the inlining decissions but
> > if there where a simple really_inline & really_dont_inline which would
> > be done after gccs automatic inlining decissions had been finished. then
> > we could easly amend gccs decissions where gcc makes mistakes instead
> > of tuning knobs on a big black box in the hope that it would reduce the
> > bad decissions
> 
> What possible benefit could be gained from having gcc think a function is a 
> different size from what it actually is when deciding whether to 
> automatically inline it, which is what you're asking for?

the gain is that you CAN override gcc if it makes a misstake, and gcc inliner
is wrong more often then not ...


>  What you're 
> advocating here is _different_ behaviour from if you copy/pasted the code, 

yes, but iam happy with either, a attribute which does what copy/paste does
or one which is done after gccs random inliner. the only thing i cant use
is one which is used during the totally broken heuristic gcc uses for
inlining

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct awnser.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070622/e59eea65/attachment.pgp>