From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16364 invoked by alias); 24 Jul 2012 09:22:30 -0000 Received: (qmail 16352 invoked by uid 22791); 24 Jul 2012 09:22:29 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED 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, 24 Jul 2012 09:22:15 +0000 From: "abel at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/53975] [ia64] Target register of a speculative load moved to a branch register prior to the chk.s instruction Date: Tue, 24 Jul 2012 09:22:00 -0000 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: abel at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- 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 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: 2012-07/txt/msg01831.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53975 --- Comment #14 from Andrey Belevantsev 2012-07-24 09:22:14 UTC --- The problem is that we don't handle this type of speculation well in sel-sched. While moving an insn through speculation check, it is hard to decide for us whether it is safe, while it's simpler in haifa with explicit dependency lists. In this case, we have a true dependency to the load which in the old scheduler would be moved to the check instead with the correct speculation bits, and thus the backend will have a chance to allow or deny speculation (note that currently it denis all of those "secondary" speculations anyways). In sel-sched we have only a check which does not longer write an address register but just reads it, thus we no longer have a true dependency. Previosly, we just banned any insns that read registers to move through a check, but later we (incorrectly) "fixed" it by only considering registers that are written by the check. So either we revert the patch at http://gcc.gnu.org/viewcvs?view=revision&revision=177658 or we add e.g. clobbers of address register to the check patterns in ia64.md _and_ allow limited instructions (e.g. ones writing to general or fp regs) for BE_IN_SPEC speculation in ia64.c, i.e. to be moved up past a speculation check.