From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19173 invoked by alias); 19 Nov 2010 08:27:02 -0000 Received: (qmail 19164 invoked by uid 22791); 19 Nov 2010 08:27:01 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_FC X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 19 Nov 2010 08:26:57 +0000 From: "hubicka at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/46555] New: PHI RTL expansion leads to CSiBE regression X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: hubicka at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Fri, 19 Nov 2010 08:39:00 -0000 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-11/txt/msg02427.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46555 Summary: PHI RTL expansion leads to CSiBE regression Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned@gcc.gnu.org ReportedBy: hubicka@gcc.gnu.org Created attachment 22452 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22452 testcase (OpenTCP-1.0.4/icmp.c) Hi, the problem here seems to be worse regalloc and also # D.4060_6 = PHI <-1(2), -1(9), -1(11), -1(14), 0(15), -1(10)> used to be optimized into since set of var to -1 (4 bytes), while now we produce 3 different copies. Crossjumping would unify it, but very late in the game. The problem is that ifcvt actually moves the set before conditoinal guarding the BB in question, so the individual sets are drifted earlier to different places in the program. Doing so might also complicate the regalloc. Michael, perhaps we can tell out-of-ssa to unify such cases? They are not that infrequent (and I think old tree based out-of-ssa did that?)