From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18644 invoked by alias); 7 Feb 2011 16:27:55 -0000 Received: (qmail 18631 invoked by uid 22791); 7 Feb 2011 16:27:54 -0000 X-SWARE-Spam-Status: No, hits=-2.6 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; Mon, 07 Feb 2011 16:27:50 +0000 From: "law at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/38644] [4.3/4.4/4.5/4.6 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: law at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.3.6 X-Bugzilla-Changed-Fields: CC 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: Mon, 07 Feb 2011 16: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: 2011-02/txt/msg00871.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644 Jeffrey A. Law changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |law at redhat dot com --- Comment #34 from Jeffrey A. Law 2011-02-07 16:27:24 UTC --- Typically the right thing to do is to block all memory motions across a change in the stack pointer. It's somewhat overly pessimistic, but in reality the few motions lost aren't going to be performance critical. In the past each backend has emitted the blockage/barrier and it typically happened soon after the port was converted to use RTL prologues/epilogues... That's probably the main reason why this was never fixed in the scheduler itself -- the first couple ports emitted a blockage and after that it became normal practice. I would support both emitting the suitable blockage insn in the ARM backend or adding a dependency between the stack pointer adjustment insn and all memory insns in the scheduler. Either is IMHO acceptable given history. The first would be slightly preferred during this late stage of development with the latter being more appropriate in early stage development.