This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Sigh. Inlining heuristics.


Mark Mitchell <mark@codesourcery.com> writes:

>> An inlining limit of 15,000 instructions is just completely ridiculous.
> 
> I agree.  We did this for compatible with the RTL inliner -- which
> had no limit at all until some time back we made it have 10,000
> instructions as a limit, to approximate the old behavior but have
> *some* cap.
> 
> I suggest we drop it to 100 or 1000 instructions by default, and see
> how that does.  We could *still* use better heuristics, but that might
> make things better in the typical case -- enough so that we might
> not need the better heuristics just yet.  And, now that all this
> stuff is run-time tunable, users can always crank the number back
> up if they need to.
> 
> Joe is right as well; if you can get a 10,000 instruction function out
> of your test-case, V3 is putting `inline' in too many places.  Note
> that making V3 functions non-inline will help in lots of ways, with
> respect to compile-time.  For example, we will throw away their bodies
> when we are done with them, instead of keeping them around for later
> inlining.

No, this isn't right, and i know why.
It's because we default methods to inline in the *compiler*.
I noticed this tonight.
flag_default_inline == 1 by default (see decl2.c)

and in start_method, we say
if (flag_default_inline)
        DECL_INLINE (fndecl) = 1


Bing bang boom, all methods are now inline.


--Dan

> 
> -- 
> Mark Mitchell                mark@codesourcery.com
> CodeSourcery, LLC            http://www.codesourcery.com

-- 
"I couldn't find the remote control to the remote control.
"-Steven Wright


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]