[Bug tree-optimization/44688] [4.6 Regression] Excessive code-size growth at -O3

[Bug tree-optimization/44688] [4.6 Regression] Excessive code-size growth at -O3

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44688

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.01.19 14:49:39
     Ever Confirmed|0                           |1

--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-01-19 14:49:39 UTC ---
Confirmed.

Leslie3d code-size almost doubled compared to 4.5 (and is even worse compared
to 4.4).

With -O3 -ffast-math -funroll-loops -fprefetch-loop-arrays
> ls -l benchspec/CPU2006/437.leslie3d/run/build_base_amd64-m64-gcc42-nn.0000/leslie3d 
-rwxrwxr-x 1 rguenther suse 572893 Jan 19 13:11
benchspec/CPU2006/437.leslie3d/run/build_base_amd64-m64-gcc42-nn.0000/leslie3d

With -O3 -ffast-math -funroll-loops
> ls -l benchspec/CPU2006/437.leslie3d/run/build_base_amd64-m64-gcc42-nn.0000/leslie3d 
-rwxrwxr-x 1 rguenther suse 368093 Jan 19 13:14
benchspec/CPU2006/437.leslie3d/run/build_base_amd64-m64-gcc42-nn.0000/leslie3d

so the regression is mostly prefetching enabled at -O3 for AMD archs.

prefetching + RTL loop unrolling: 638680
prefetching: 356736
: 274088

there are several issues.

1) prefetching doesn't re-use the epilogue loop created by the vectorizer
2) the RTL loop unroller unrolls both epilogue loops
3) for both epilogue loops we usually know an integer upper bound for
the number of iterations, but we are not able to compute it

also the vectorizer checks use various different variables to test
bounds agains which doesn't even allow us to simplify the effective
niter == 0 || niter <= 6 style tests ... that obviously does not
help the situation.

On the tree level we see things like

<bb 7>:
  vectorizer check
  if (bnd.24_140 <= 1)
    goto <bb 12>;  // unvectorized loop
  else
    goto <bb 8>;

<bb 8>:
  prefetcher check
  if (bnd.24_140 > 4)
    goto <bb 9>;
  else
    goto <bb 14>;

<bb 9>:
<bb 10>:
  # ivtmp.36_174 = PHI <0(9), ivtmp.36_197(10)>
  ivtmp.36_197 = ivtmp.36_174 + 4;
  if (...)
    goto <bb 10>;
  else
    goto <bb 14>;

<bb 14>:
  # ivtmp.36_176 = PHI <0(8), ivtmp.36_197(10)>

<bb 15>:
  # ivtmp.36_193 = PHI <ivtmp.36_176(14), ivtmp.36_192(15)>
  ivtmp.36_192 = ivtmp.36_193 + 1;
  if (bnd.24_140 <= ivtmp.36_192)
    goto <bb 11>;
  else
    goto <bb 15>;

and we should be able to derive that the epilogue loop runs at most
3 times.  On RTL this seems to be difficult also because we changed
IVs again to pointers.

So the things to do are:

 1) preserve loop information across expand (and up to loop2_init)
 2) compute number of iteration information right before expand
 3) make IPA inlining integration be performed before tree loop optimizers
 4) preserve loop information starting with tree loop optimizers
 5) ...

In the end this regression shows at -O3 - an optimization flag setting
that is documented to eventually have this kind of effects.  P2.

[Bug tree-optimization/44688] [4.6/4.7 Regression] Excessive code-size growth at -O3

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44688

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.6.0                       |4.6.1

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-03-25 19:52:59 UTC ---
GCC 4.6.0 is being released, adjusting target milestone.

[Bug tree-optimization/44688] [4.6/4.7 Regression] Excessive code-size growth at -O3

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44688

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.6.1                       |4.6.2

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-06-27 12:33:06 UTC ---
GCC 4.6.1 is being released.

[Bug tree-optimization/44688] [4.6/4.7 Regression] Excessive code-size growth at -O3

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44688

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.6.2                       |4.6.3

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-10-26 17:13:51 UTC ---
GCC 4.6.2 is being released.

[Bug tree-optimization/44688] [4.6/4.7 Regression] Excessive code-size growth at -O3

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44688

--- Comment #6 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-02-22 10:11:11 UTC ---
Testcase:

void foo (int * __restrict a, int * __restrict b, int * __restrict c, 
          unsigned n)
{
  unsigned i;
  for (i = 0; i < n; ++i)
    a[i] = b[i] + c[i];
}

[Bug tree-optimization/44688] [4.6/4.7 Regression] Excessive code-size growth at -O3

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44688

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.6.3                       |4.6.4

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-03-01 14:39:05 UTC ---
GCC 4.6.3 is being released.

[Bug tree-optimization/44688] [4.6/4.7/4.8 Regression] Excessive code-size growth at -O3

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44688

--- Comment #8 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-04-18 11:34:01 UTC ---
Author: rguenth
Date: Wed Apr 18 11:33:51 2012
New Revision: 186566

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186566
Log:
2012-04-18  Richard Guenther  <rguenther@suse.de>

    PR tree-optimization/44688
    * cfgloop.h (record_niter_bound): Declare.
    * tree-ssa-loop-niter.c (record_niter_bound): Export.
    Update the estimation with the upper bound here...
    (estimate_numbers_of_iterations_loop): ... instead of here.
    Do not forcefully reset a recorded upper bound.
    * tree-vect-loop-manip.c (vect_do_peeling_for_alignment):
    Record the maximum number of loop iterations of the
    prologue loop.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cfgloop.h
    trunk/gcc/tree-ssa-loop-niter.c
    trunk/gcc/tree-vect-loop-manip.c

[Bug tree-optimization/44688] [4.6/4.7/4.8 Regression] Excessive code-size growth at -O3

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44688

--- Comment #9 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-04-19 08:51:57 UTC ---
Author: rguenth
Date: Thu Apr 19 08:51:50 2012
New Revision: 186585

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186585
Log:
2012-04-19  Richard Guenther  <rguenther@suse.de>

    PR rtl-optimization/44688
    * loop-iv.c (determine_max_iter): Only return max_iter.
    (iv_number_of_iterations): Also use the recorded loop bound
    on the maximum number of iterations.
    * loop-unroll.c (decide_unroll_runtime_iterations): Use
    max_iter to avoid unrolling loops that do not roll.
    (decide_unroll_stupid): Likewise.

    * gcc.dg/var-expand1.c: Increase array size to make unrolling
    possibly profitable.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/loop-iv.c
    trunk/gcc/loop-unroll.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.dg/var-expand1.c

[Bug tree-optimization/44688] [4.6/4.7/4.8 Regression] Excessive code-size growth at -O3

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44688

--- Comment #10 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-04-19 08:53:37 UTC ---
There are still other prologue/epilogue loops that would need similar handling
on their generation.  The vectorizer needs to be re-organized to better
separate those loop versions again.

[Bug tree-optimization/44688] [4.6/4.7/4.8 Regression] Excessive code-size growth at -O3

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44688

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |rguenth at gcc dot gnu.org
                   |gnu.org                     |

[Bug tree-optimization/44688] [4.6/4.7/4.8 Regression] Excessive code-size growth at -O3

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44688

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
      Known to work|                            |4.8.0
         Resolution|                            |FIXED
   Target Milestone|4.6.4                       |4.8.0
      Known to fail|                            |4.6.4, 4.7.2

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> 2012-12-11 10:26:30 UTC ---
The original reason for this bug, compile-time and code-size growth of SPEC CPU
2006 and Polyhedron on AMD Barcelona with -march=native has been fixed (back
to levels before the -fprefetch-loop-arrays defaulting).  For 4.8, that is.

Backporting not really possible (requires preserving of loop structure), thus
wontfix on the branches.