[FFmpeg-devel] MPEG-2 Acceleration Refactor

[Michael Niedermayer]

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


> 
> 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.

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


-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin
-------------- 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/c4f2b14a/attachment.pgp>