From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14155 invoked by alias); 6 May 2011 12:44:09 -0000 Received: (qmail 14141 invoked by uid 22791); 6 May 2011 12:44:08 -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; Fri, 06 May 2011 12:43:55 +0000 From: "abel at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/48673] [4.7 Regression] GCC generates WAW and RAW conflicts on IA64. X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: abel at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.7.0 X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: 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, 06 May 2011 12:44: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-05/txt/msg00567.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48673 --- Comment #7 from Andrey Belevantsev 2011-05-06 12:33:39 UTC --- (In reply to comment #6) > (In reply to comment #5) > > Or schedule_block could have a mode of preserving the existing insn order, > > which can also be useful for testing purposes. If this sounds like an > > overkill, something like sel-sched.c:reset_sched_cycles_in_current_ebb could be > > adapted to work. This function feeds the bb insns to DFA but also follows the > > old schedule w.r.t. to dependency latencies. Not having the old schedule would > > mean that we would honor only DFA latencies reflected in insn cycles and > > TImodes, but this may be enough. > > That sounds fragile. The DFA is not sufficient to produce an accurate schedule > on all targets. If SMS produces a schedule it might as well mark it with > accurate uses of TImode. But sms works too early. There is no guarantee that TImode markers will live until machreorg, where we need them. Also, for the before reload scheduler there is no guarantee the schedule would be fully accurate. If you are saying that just DFA is not enough for making proper TImodes, then IMHO the only choice is to have the full run of schedule_block preserving insn order and taking into account all of DFA/dependency/target hook stuff just before the machreorg pass.