[FFmpeg-devel] MPEG-2 Acceleration Refactor

Michael Donaghy md401
Fri Jun 22 10:54:06 CEST 2007


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! 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.
>
> 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? What you're 
advocating here is _different_ behaviour from if you copy/pasted the code, 
which is patently wrong; whether or not the function you get when its 
subfunctions are inlined should be inlined is the same decision about the 
same code whether this function was originally written like this (via 
copy/paste) or inlined.

Michael
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070622/b2c22ec4/attachment.pgp>



More information about the ffmpeg-devel mailing list