Inlining again...

Inlining again...

[Richard Guenther]

Hi!

I just wondered today why contrary to --param min-inline-insns=250 still
empty destructors and random other stuff do not get inlined and stumbled
over the following code in tree-inline.c:inlinable_function_p

      ...
      /* 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;
      else ...

I just placed a warning here, and viola - it triggered 89729 times until
I killed it off. This is of course special for my personal code which is
based on the POOMA library.

Killing the offending check with

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.

So I vote to apply the above patch and see, if anyone with "Real World
Code"(TM) complains ;)

Richard.

Re: 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.

Re: Inlining again...

[Steven Bosscher]

Op wo 07-05-2003, om 20:17 schreef Richard Guenther:
> 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?

You can look at that in gdb:

(gdb) b tree-inline.c:inlinable_function_p

Then run for some time until you hit the breakpoint, and do:

(gdb) p (fn->decl.u1.i * 10)

That's your stmt count: 130 if you repace "some code" with "return;":

template <bool f>
struct blah {
	void foo() { if (f) { return; } }
};

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

Yes. 130. I can only: ouch.

Greetz
Steven

Re: Inlining again...

[Richard Guenther]

On 7 May 2003, Steven Bosscher wrote:

> Op wo 07-05-2003, om 20:17 schreef Richard Guenther:
> > Note that I just checked and found that _still_ not all empty functions
> > are inlined... btw. how is the following counted insns wise?
> >
> > is in this case the size of foo counted with or without the code inside
> > the if statement?
>
> You can look at that in gdb:
>
> (gdb) b tree-inline.c:inlinable_function_p
>
> Then run for some time until you hit the breakpoint, and do:
>
> (gdb) p (fn->decl.u1.i * 10)
>
> That's your stmt count: 130 if you repace "some code" with "return;":
>
> template <bool f>
> struct blah {
> 	void foo() { if (f) { return; } }
> };
>
> void bar()
> {
> 	blah<false>().foo();
> }
>
> Yes. 130. I can only: ouch.

Ouch. I suppose this wont improve until we get at least, say, DCE at the
tree level? Dont we have something like that - I remember a patch during
the last month doing early DCE...

http://gcc.gnu.org/ml/gcc-patches/2003-03/msg02443.html

Roger - does this "help" insn counting for inlining or is this already too
late? Maybe we can even get this into 3.3.1 if it helps ... (I'll check it
out, if it applies to 3.3)

Richard.

Re: Inlining again...

[Steven Bosscher]

Op wo 07-05-2003, om 21:22 schreef Richard Guenther:
> > That's your stmt count: 130 if you repace "some code" with "return;":
> >
> > template <bool f>
> > struct blah {
> > 	void foo() { if (f) { return; } }
> > };
> >
> > void bar()
> > {
> > 	blah<false>().foo();
> > }
> >
> > Yes. 130. I can only: ouch.
> 
> Ouch. I suppose this wont improve until we get at least, say, DCE at the
> tree level? Dont we have something like that - I remember a patch during
> the last month doing early DCE...

That patch is unrelated.  It deals with expanding to RTL which is
exactly what we do _not_ do with inlinable functions.  Like I've said
earlier, this is a front end issue.

Greetz
Steven