3_3-branch: Honor MIN_INLINE_INSNS

[Kurt Garloff <kurt at garloff dot de>]

Hi Mark,

I'm trying to understand the following change in gcc-3_3-branch:

2003-07-23  Mark Mitchell  <mark@codesourcery.com>

        PR optimization/10679
        * tree-inline.c (inlinable_function_p): Honor MIN_INLINE_INSNS.

The logic before this change was (simplified pseudo-C):

	int inlinable = (currfn_insns <= MAX_INLINE_LIMIT_SINGLE);
	if (inlinable) {
		if (sum_insns > 128*MAX_INLINE_LIMIT)
			inlinable = 0;
		else if (sum_insns > MAX_INLINE_LIMIT &&
			 currfn_insns > MIN_INLINE_LIMT) {
			int max_curr = decr_function_of_sum_insns(...);
			if (currfn_insns > max_curr)
				inlinable = 0;
		}
	}

There are a few ideas behind: 
* When we have inlined a lot of instructions already (by recursive
  inlining), we should start to reduce the allowable size for single
  functions to avoid building huge inlined functions this way.
  (We learned this from history: In 3.0, we completely stopped 
   inlining then which was desastrous for the performance of some test 
   programs (ask Gerald), in 2.95 we could make large irons go OOM 
   because such a limit was not existing at all.)
* The function that reduces the allowable size has a minimum 
  (MIN_INLINE_INSNS) to protect very small functions. Namely accessors
  in OOP languages, which are paramount for performance to inline.
* If we manage to have created a function that is huge (128 times the
  size of our limit), we even stop with the small functions to make sure
  that the ressource consumption of our compiler stays finite.

After your change, the (pseudo-)code looks like 

	int inlinable = (currfn_insns <= MAX_INLINE_LIMIT_SINGLE);
	if (inlinable && currfn_insns > MIN_INLINE_LIMIT) {
		if (sum_insns > 128*MAX_INLINE_LIMIT)
			inlinable = 0;	
		else if (sum_insns > MAX_INLINE_LIMIT) {
			int max_curr = decr_function_of_sum_insns(...);
			if (currfn_insns > max_curr)
				inlinable = 0;
		}
	}

Basically this change means that we always inline functions that are
smaller than MIN_INLINE_LIMIT, no matter how much recursive inlining
we've already done. I.e. we drop the sanity check that tries to keep
the compiler from never stopping with recursive inlining.
The (sum_insns > 128*MAX_INLINE_LIMIT) check could be dropped as well,
as it won't be triggered for any sane choice of parameters
MAX_INLINE_INSNS_SINGLE, MAX_INLINE_INSNS, MAX_INLINE_INSNS_SLOPE.

I don't really believe the fix is right.

With normal code, you should not be able to do enough inlining to 
hit the 128*MAX_INLINE_LIMIT limit.
This limit was only menat as last resort to protect against unlimited
ressource consumption in the compiler.

I'm looking at PR/10679 and get the idea that the testcase is quite 
artificial. And the failure is caused by the fact that the accounting 
of instructions is apparently poor. The sum_insns basically should 
not increase by inlining empty functions ...

Apparently, POOMA does do similar strange things as the testcase.

So, my suggestion to fix this correctly would be:
* Increase the 128 to 1024 or something (but leave a limit there
  to have some limit on inlining and thus on ressource consumption).
* Improve the accounting of instructions to be more realistic.

Otherwise, we can probably construct a testcase with small but non-empty
functions (containing non-dead code) that makes gcc eat arbitrary
amounts of memory and CPU time during compilation. 

If you think that we need to take that risk in order to produce optimal
code in all cases, we should remove the (sum_insns >
128*MAX_INLINE_LIMIT) test completely.


PS: Richard: You should use the TBCI library rather than POOMA ;-)

Best regards,
-- 
Kurt Garloff                   <kurt@garloff.de>             [Koeln, DE]
Physics:Plasma modeling <garloff@plasimo.phys.tue.nl> [TU Eindhoven, NL]
Linux:SCSI, Security           <garloff@suse.de>    [SuSE Nuernberg, DE]

Attachment: pgp00000.pgp
Description: PGP signature