From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30546 invoked by alias); 16 Jul 2010 14:41:01 -0000 Received: (qmail 30535 invoked by uid 22791); 16 Jul 2010 14:41:00 -0000 X-SWARE-Spam-Status: No, hits=-0.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KAM_VIAGRA1 X-Spam-Check-By: sourceware.org Received: from mail-gy0-f175.google.com (HELO mail-gy0-f175.google.com) (209.85.160.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 16 Jul 2010 14:40:51 +0000 Received: by gya6 with SMTP id 6so1465621gya.20 for ; Fri, 16 Jul 2010 07:40:49 -0700 (PDT) Received: by 10.224.101.10 with SMTP id a10mr888532qao.230.1279291245319; Fri, 16 Jul 2010 07:40:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.29.9 with HTTP; Fri, 16 Jul 2010 07:40:15 -0700 (PDT) In-Reply-To: References: <1279263843-9149-1-git-send-email-sebpop@gmail.com> <1279263843-9149-7-git-send-email-sebpop@gmail.com> From: Sebastian Pop Date: Fri, 16 Jul 2010 14:41:00 -0000 Message-ID: Subject: Re: [PATCH 06/12] Bump the size of scevs. To: Richard Guenther Cc: gcc-patches@gcc.gnu.org, gcc-graphite@googlegroups.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2010-07/txt/msg01363.txt.bz2 On Fri, Jul 16, 2010 at 03:03, Richard Guenther wrote: > On Fri, Jul 16, 2010 at 9:03 AM, Sebastian Pop wrote: >> 2010-07-15 =A0Sebastian Pop =A0 >> >> =A0 =A0 =A0 =A0* params.def (PARAM_SCEV_MAX_EXPR_SIZE): Bump the value t= o 100. > > What's the effect on compile-time here? PARAM_SCEV_MAX_EXPR_SIZE was introduced to solve http://gcc.gnu.org/PR20742 I see that we never committed the testcase for that PR. With a slightly modified testcase: /* { dg-do compile } */ /* { dg-options "-O2" } */ #define TEN(x) x x x x x x x x x x #define THOUSAND(x) TEN (TEN (TEN (x))) int foo (int x, int y) { register int a =3D y + 57; register int b =3D y + 31; while (x-- > 0) { TEN (THOUSAND (a +=3D b; b -=3D a;)) } return a + b; } I am seeing this with the Graphite branch (passes taking more than a second): tree SSA verifier : 1.92 (16%) usr 0.00 ( 0%) sys 1.96 (16%) wall 0 kB ( 0%) ggc tree STMT verifier : 4.17 (35%) usr 0.04 (25%) sys 4.26 (35%) wall 0 kB ( 0%) ggc combiner : 1.15 (10%) usr 0.00 ( 0%) sys 1.17 ( 9%) wall 5664 kB (10%) ggc TOTAL : 11.96 0.16 12.32 58997 kB These passes are not using the scev analysis. Without the patch I am seeing the exact same thing: tree SSA verifier : 1.86 (15%) usr 0.01 ( 4%) sys 1.93 (15%) wall 0 kB ( 0%) ggc tree STMT verifier : 4.12 (34%) usr 0.09 (36%) sys 4.23 (33%) wall 0 kB ( 0%) ggc combiner : 1.17 (10%) usr 0.00 ( 0%) sys 1.19 ( 9%) wall 5664 kB ( 9%) ggc TOTAL : 12.25 0.25 12.64 61271 kB I will probably add a testcase with a THOUSAND operations to the tree-ssa testsuite. Sebastian