From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12807 invoked by alias); 29 Jan 2003 01:36:01 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 12793 invoked by uid 71); 29 Jan 2003 01:36:01 -0000 Date: Wed, 29 Jan 2003 01:36:00 -0000 Message-ID: <20030129013601.12792.qmail@sources.redhat.com> To: ebotcazou@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Gabriel Dos_Reis Subject: Re: optimization/9279: [3.2 regression] [Sparc] combine bug Reply-To: Gabriel Dos_Reis X-SW-Source: 2003-01/txt/msg01651.txt.bz2 List-Id: The following reply was made to PR optimization/9279; it has been noted by GNATS. From: Gabriel Dos_Reis To: Eric Botcazou Cc: Matthias Klose , frank@g-n-u.de, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org Subject: Re: optimization/9279: [3.2 regression] [Sparc] combine bug Date: Wed, 29 Jan 2003 02:29:15 +0100 (MET) | > As I explained to Eric, I would have been pleased to apply that | > patch. However it turned out that it introduces (1) a performance | > regression; (2) possibly a wrong code generation -- David gave some | > references. | | Note that, as I said to David, I'm very skeptical about (2) for the patch | _alone_ because it simply pessimizes (however rightfully, they are just | plain wrong in the general case) the values returned by two predicate | functions: Sorry, I mistranslated your agreement on David's statement: > This patch and the necessary PowerPC patch exposed other bugs in > the compiler regarding REG_EQUAL notes in loop unrolling: > > 2002-10-04 David Edelsohn > > * unroll.c (copy_loop_body): Remove REG_EQUAL note attached to > copied instruction if the note is not loop invariant. > > The patches may have other co-dependencies we do not know about. Ok. [...] | > I would suggest that, right after 3.2.2 release, interested parties | > investigate the issue and submit a complete patch which we would | > have sufficient time to test. | | I'm not very optimistic about this happening. I guess most of the developer | resources will be focused on the 3.3 branch instead. Well, that is just a suggestion. I hope 3.3 will be ready in time so that 3.2-branch becomes obselete. -- Gaby