Inlining again...

[Richard Guenther]

On Wed, 7 May 2003, Richard Guenther wrote:

> Index: tree-inline.c
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/tree-inline.c,v
> retrieving revision 1.38.2.8
> diff -u -u -r1.38.2.8 tree-inline.c
> --- tree-inline.c	2 May 2003 19:52:01 -0000	1.38.2.8
> +++ tree-inline.c	7 May 2003 17:36:26 -0000
> @@ -1007,17 +1007,12 @@
>      {
>        int sum_insns = (id ? id->inlined_stmts : 0) * INSNS_PER_STMT
>  		     + currfn_insns;
> -      /* In the extreme case that we have exceeded the recursive inlining
> -         limit by a huge factor (128), we just say no. Should not happen
> -         in real life.  */
> -      if (sum_insns > MAX_INLINE_INSNS * 128)
> -	 inlinable = 0;
>        /* If we did not hit the extreme limit, we use a linear function
>           with slope -1/MAX_INLINE_SLOPE to exceedingly decrease the
>           allowable size. We always allow a size of MIN_INLINE_INSNS
>           though.  */
> -      else if ((sum_insns > MAX_INLINE_INSNS)
> -	       && (currfn_insns > MIN_INLINE_INSNS))
> +      if ((sum_insns > MAX_INLINE_INSNS)
> +	  && (currfn_insns > MIN_INLINE_INSNS))
>  	{
>  	  int max_curr = MAX_INLINE_INSNS_SINGLE
>  			- (sum_insns - MAX_INLINE_INSNS) / MAX_INLINE_SLOPE;
>
>
> increases compile time for my program from about 9 minutes to 20 minutes,
> but gets a performance increase in the running code from 185.913s/it to
> 143.996s/it - a 30% increase in performace.
>
> I think the hunk above, while it protects against unusual long compile
> times, goes against the spirit of min-inline-insns parameter and hurts
> optimization much.

Note that I just checked and found that _still_ not all empty functions
are inlined... btw. how is the following counted insns wise?

template <bool f>
struct blah {
	void foo() { if (f) { ... some code ... } }
};

void bar()
{
	blah<false>().foo();
}

is in this case the size of foo counted with or without the code inside
the if statement?

Richard.