From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11314 invoked by alias); 14 Jan 2009 22:06:45 -0000 Received: (qmail 11254 invoked by uid 48); 14 Jan 2009 22:06:31 -0000 Date: Wed, 14 Jan 2009 22:06:00 -0000 Message-ID: <20090114220631.11253.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug tree-optimization/38785] huge performance regression on EEMBC bitmnp01 In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "amylaar 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-01/txt/msg01552.txt.bz2 ------- Comment #11 from amylaar at gcc dot gnu dot org 2009-01-14 22:06 ------- (In reply to comment #10) > You would completely underestimate the optimization opportunities PRE > unleashes. Well, at least for partial-partial-RE, as mentioned before in PR38401, benchmarks indicate that we'd be better without it altogether than what it is in its current form. If we could use a cost calculation to avoid the code pessimization while keeping some of the potential penefit of partial-partial-RE, that should be even better. The potentially harmful impact of ordinary PRE is lesser because if you put in a constant load where the expression is at least fully anticipatable, you swap a constant load for some other operation, worst case that means an expensive constant load and two branches instead of a simple icond-exec operation - that's bad, but not nearly as bad as blowing up always-executed path along with everything else exponentially. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38785