[FFmpeg-devel] MPEG-2 Acceleration Refactor
Fri Jun 22 13:30:39 CEST 2007
On Fri, Jun 22, 2007 at 02:02:20AM -0700, Trent Piepho wrote:
> On Fri, 22 Jun 2007, Michael Niedermayer wrote:
> > if yes then this is a new gcc bug, that is gcc inlines fewer functions
> > with av_always_inline but there is not a single function it inlines in the
> > av_always_inline case which wasnt already inlined wthout it
> > 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)
> gcc will do a lot of inlining without any kind of inline keywords or
> attributes at all. There are a number of parameters that control this.
> Imagine three functions, A which calls B which calls C. One could inline B
> into A, but not inline C into A+B. Or inline C into B, but not inline B+C
> into A. Or inline all three.
> Suppose functions A and B are small, but C is big.
> In one inline directives are used, gcc might decide to inline B into A, but
> not inline C. If you now add an inline directive to C, gcc will inline C into
> B, and the new big B+C function won't be inlined into A.
makes sense iam fully agreeing with you here but this has nothing to do with
gcc stops inlining unrelated funtions if inlining of a function is forced
which was already inlined without the always_inline
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the ffmpeg-devel