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.



On Tue, 10 Jul 2001 dewar@gnat.com wrote:
>
> <<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.
> >>
>
> I would think that 100 is just fine, and I cannot imagine any user needing
> to deoptimize their program by cranking the number up (it is equally hard
> to imagine any program that would be measurably improved by the old limit,
> but very easy to imagine programs that are damaged).

Well, there _is_ another issue.

Inline functions are useful for macro-like things, and it depends on WHEN
you coult the instructions necessary for the inlined fn.

For example, constant arguments may make 99% of the inlined function go
away statically - but if you make your instruction estimate based on the
pre-optimized tree (which I assume you'd do - anything else would be
rather expensive), you'd never see this.

I'm not sure how common (if at all) this is, but it might be worthwhile to
have heuristics that take constant arguments (especially small constants
and truth values) into account. And let the user give hints (the obvious
hint is just the "inline" keyword, of course).

			Linus


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