From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17067 invoked by alias); 19 Feb 2010 13:19:28 -0000 Received: (qmail 16998 invoked by uid 48); 19 Feb 2010 13:19:15 -0000 Date: Fri, 19 Feb 2010 13:19:00 -0000 Message-ID: <20100219131915.16997.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug tree-optimization/38785] [4.3/4.4/4.5 Regression] huge performance regression on EEMBC bitmnp01 In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "matz at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-02/txt/msg01937.txt.bz2 ------- Comment #23 from matz at gcc dot gnu dot org 2010-02-19 13:19 ------- Richi: not really. It tries to separate paths where at least one has mostly constants in their PHI args. This applies to this testcase for the first chain of PHI nodes, which are separated as intended. But this simply leads to constant propagation into the next chain of PHI nodes. If repeated until nothing changes this just ripples down the constants further and further but doubles the number of incoming edges for the successor blocks. Until we have the exponential growth in the number of edges, not the number of PHI nodes. I.e. effectively all possible paths are then represented by an edge, as would be expected from a tracer. At that point the last PHI node with constants then would be useless and removed. But we still would have exponential code size growth. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38785