[patch] PR pch/53880

[Steven Bosscher]

Hello,

This PR concerns a huge compile time regression since
-ftrack-macro-expansion=2 became the default. It turns out that
gengtype generates code that is quadratic in the GTY((length)) of
arrays, and in this case (a PCH for a Boost header...) there are 183k
maps for macro expansion line maps in such an array. For comparison:
there are 2732 "ordinary" line maps...

The solution I've come up with, is to hoist a check that's inside the
loop over the elements in the array into the loop test, so that you
get changes in gtype-desc.c like this:

@@ -8963,7 +8963,7 @@ gt_pch_p_9line_maps (ATTRIBUTE_UNUSED vo
     size_t l0 = (size_t)(((*x).info_ordinary).used);
     if ((*x).info_ordinary.maps != NULL) {
       size_t i0;
-      for (i0 = 0; i0 != (size_t)(l0); i0++) {
+      for (i0 = 0; i0 != (size_t)(l0) && ((void
*)(*x).info_ordinary.maps == this_obj); i0++) {
         switch (((*x).info_ordinary.maps[i0]).reason == LC_ENTER_MACRO)
           {
           case 0:

Inside the loop there are more tests against this_obj, but GCC cannot
perform the unswitching with -funswitch-loops because it cannot
determine that the test is loop invariant (everything is a void*
pointer, there are indirect function calls, and all kinds of other
nasty stuff that inhibit good optimization of the gt-* stuff). So my
patch makes gengtype emit the test in the loop test.

The effect is quite dramatic: Compile time for the test case goes from
>9 minutes to 12 seconds on powerpc64-unknown-linux-gnu :-)

Bootstrapped&tested on powerpc64-unknown-linux-gnu. OK for trunk?

Ciao!
Steven

PR53880.diff
Description: Binary data