From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19749 invoked by alias); 1 Dec 2009 15:36:03 -0000 Received: (qmail 19691 invoked by alias); 1 Dec 2009 15:35:49 -0000 Date: Tue, 01 Dec 2009 15:36:00 -0000 Message-ID: <20091201153549.19690.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug tree-optimization/42216] [4.5 Regression] rev 15458[78] regress 464.h264ref peak 20% In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "rguenther at suse dot de" 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/msg00052.txt.bz2 ------- Comment #6 from rguenther at suse dot de 2009-12-01 15:35 ------- Subject: Re: [4.5 Regression] rev 15458[78] regress 464.h264ref peak 20% On Tue, 1 Dec 2009, bernds_cb1 at t-online dot de wrote: > ------- Comment #5 from bernds_cb1 at t-online dot de 2009-12-01 15:26 ------- > Code generation changes are expected for two reasons - the code became less > conservative when determining conflicts with other registers, so we can usually > rename in more cases. There are also a few cases where we have to give up on > renaming due to multiword hard register overlaps we can't track. > > Unfortunately I don't have access to spec; I'll have to think about how to > track this down. I will try to come up with a testcase for you. I suppose it might be a backend issue as regrename should mainly effect the 2nd scheduling pass, right? Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42216