From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11572 invoked by alias); 14 Dec 2009 16:58:46 -0000 Received: (qmail 11498 invoked by uid 48); 14 Dec 2009 16:58:36 -0000 Date: Mon, 14 Dec 2009 16:58:00 -0000 Message-ID: <20091214165836.11497.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug tree-optimization/42108] [4.4/4.5 Regression] 50% performance regression 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: 2009-12/txt/msg01376.txt.bz2 ------- Comment #35 from matz at gcc dot gnu dot org 2009-12-14 16:58 ------- Exactly my thinking (growing SCCs -> slow, sorting SCCs -> difficult). What I thought about the trapping problem is that in this situation we could ignore the trap test. We start with this situation: bb1: goto bb2 bb2: PHI ; with bbX being dominated by bb1 a = b / c ; with b and c loop invariant Now it's clear that inserting a computation b/c in bb1 does not ever introduce additional traps, as there's no intervening statement that could stop execution without us knowing (in PR38819 it's a call that does exit(0)). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108