172.mgrid performance degraded after ivopts were introduced. The patch to improve iv selection did not improve the performance. This is separate from the register pressure problems. The tree loop optimization appears to be leaving unnecessary computations in loops.
Does this go away with "--param iv-consider-all-candidates-bound=70" ? (Or with a higher number like 100 or 1000)
I think this can be confirmed because you can see the drop on Diego's SPEC tester: <http://people.redhat.com/dnovillo/spec2000/gcc/individual-run-ratio.html>.
Daniel's DOM loop depth patch might help with this problem as well. http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00931.html
Subject: Re: [4.0 Regression] mgrid loop performance regression with ivopts > Daniel's DOM loop depth patch might help with this problem as well. > http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00931.html Probably not (although large part of the regression is indeed caused by ivopts -- dom interaction, it seems to be of quite different type). I am just testing a patch that significantly decreases the regression (unfortunately, some 10% remain even with the patch; hopefully I will find reason for them soon). Zdenek
Subject: Bug 18048 CVSROOT: /cvs/gcc Module name: gcc Changes by: rakdver@gcc.gnu.org 2004-10-27 20:27:21 Modified files: gcc : ChangeLog fold-const.c tree-ssa-loop-ivopts.c tree-ssa-loop-niter.c tree.c tree.h Log message: PR tree-optimization/18048 * fold-const.c (try_move_mult_to_index): New function. (fold): Use try_move_mult_to_index. * tree-ssa-loop-ivopts.c (try_add_cand_for): Prefer common candidates. * tree-ssa-loop-niter.c (number_of_iterations_cond): Produce an all-ones unsigned constant without extra bits. * tree.c (build_low_bits_mask): New function. * tree.h (build_low_bits_mask): Declare. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6052&r2=2.6053 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gcc&r1=1.468&r2=1.469 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-ivopts.c.diff?cvsroot=gcc&r1=2.20&r2=2.21 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-ssa-loop-niter.c.diff?cvsroot=gcc&r1=2.13&r2=2.14 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.c.diff?cvsroot=gcc&r1=1.440&r2=1.441 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.h.diff?cvsroot=gcc&r1=1.640&r2=1.641
PR 19038 shows up here also but not introduced by ivopts related.
(In reply to comment #6) > PR 19038 shows up here also but not introduced by ivopts related. Though IV-OPTS helps fixing some of these.
Actually I think the remaining issues of the mgrid performance regression are caused by PR 19038.
(In reply to comment #8) > Actually I think the remaining issues of the mgrid performance regression are caused by PR 19038. Well I looked the assembly and it looks like a regresiter allocator problem now because with -fno- ivopts we don't spill but with it turned we do.
If I have a smaller testcase but the loop is still looks like what is in mgrid can I paste it here, it is only 30 lines?
The mgrid score on AMD64 jumps 30% with my patch for PR19464 applied.
Andrew, 30 lines is quite OK to paste if you rename things a bit ;-) You'll find that mgrid.f is already available on the web anyway: http://www.cs.duke.edu/~tavi/scheduling/mgrid.f
PR 19701 is an example of where ivopts causes a regression in that we create too many IVs.
I looked at the code generation after Zdenek's patch for PR 19701 and it looks much better but I don't have a machine to test SPEC on.
Is this fixed now?
(In reply to comment #15) > Is this fixed now? No, it regressed again. See <http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00507.html>.
With -O2/-O3 -funroll loops -fswitch-loops -fpeel-loops, mgrid (and swim) no longer regress. With just -O2/-O3, performance regression for mgrid remains (and swim performance dropped dramatically).
*** Bug 20945 has been marked as a duplicate of this bug. ***
Leaving as P2, since this is a SPEC benchmark issue, which many potential users and reviewers use to judge GCC performance.
Is this still a problem? The SPEC graph for mgrid on PPC has moved up lately: http://www.suse.de/~gcctest/SPEC/CFP/sb-huckleberry2-head-64/172_mgrid_big.png
Subject: Re: [4.0/4.1 Regression] mgrid loop performance regression with ivopts (register pressure) And mesa has taken a performance dive...
Yes, mesa is down. But is that related to this bug?
This bug was for mgrid, but now we're stuck on a reported mesa performance drop that may or may not be related to this PR. I suggest that if the mesa drop is still there, a new bug report should be opened for it.