From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25011 invoked by alias); 26 Apr 2011 15:00:59 -0000 Received: (qmail 24985 invoked by uid 22791); 26 Apr 2011 15:00:57 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 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; Tue, 26 Apr 2011 15:00:39 +0000 From: "mfortune at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/48773] New: Dataflow and REG_DEAD notes X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Keywords: X-Bugzilla-Severity: major X-Bugzilla-Who: mfortune at gmail dot com 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: Tue, 26 Apr 2011 15:00: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: 2011-04/txt/msg02641.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48773 Summary: Dataflow and REG_DEAD notes Product: gcc Version: 4.3.5 Status: UNCONFIRMED Severity: major Priority: P3 Component: rtl-optimization AssignedTo: unassigned@gcc.gnu.org ReportedBy: mfortune@gmail.com Hello all, I have recently been updating an out of tree target from GCC 4.2.4 to GCC 4.3.5 and have noticed that REG_DEAD notes can get out of sync at the end of multiple passes. (i.e. be attached to instructions where the register does not die) The first pass that appears to get REG_DEAD notes out of sync is GCSE. This gets fixed and broken multiple times as some of the later passes solve the DF note problem via df_analyze, some delete all notes and some get the notes out of sync again. When the second schedule pass (sched2) runs the DF note problem is solved at the start but then instructions can be re-ordered and notes are once again left out of sync. In my case this causes (an admittedly old) peephole to be applied incorrectly and bad code is generated. It seems to be that each pass, which may get notes out of sync, should run the note problem before finishing. With some experimentation I have seen that running df_analyze to solve the note problem at the end of some passes leads to an apparent improvement in the code. It would therefore seem that some passes use REG_DEAD information without first solving the REG_DEAD problem. This sounds reasonable as I would expect each pass to end leaving notes valid. Is the behaviour I have described here intentional? If so, could someone explain the rationale? I can't see any changes in this area (up to trunk) and I have seen REG_DEAD notes get out of sync with at least one in-tree target for which I could provide a testcase if that is useful (GCC 4.5.1). This issue is quite general though so I believe a large amount of code should trigger the notes to get out of sync. This clearly does not lead to actual bugs in most cases otherwise it would have already been reported. regards, Matthew