From patchwork Wed Feb 15 00:41:09 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Bernd Schmidt X-Patchwork-Id: 141220 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 1F39D1007D1 for ; Wed, 15 Feb 2012 11:41:36 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1329871297; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:Sender:Delivered-To; bh=PwRXrJg vKF3KLMKOOIs8zMHMCWg=; b=Jjrz7q1INS1Iff1Tt27RQuKvVuznzcjIcHn/Ze3 FJ3NV87ozcg+qIUukA+qfh1BbB15JF1GOQxtZKSngM+G/x0m38Otyz/KGsCeycZm Dd/nZs5OK8lv4Vg2uLsy0G+DYnn6hhY29bxKj8sd1yap1eHr9GXTZEPOZNiyWXjA Fpck= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=r554aNbK3XxSPDQN3zpxb1mOp3BpzZjkWV8zJpvVC4/6iFd/zpQALEHgbQsvj0 LlnG9MbpW/buYv5ZBZxxWcsgpE2kZiuZKwh6EXhAZM9upoHcT6RNvF71XHUvgIJO mu1RXjlBCt/FMUzSztYZ5Nmvw/oMjSpoyAAIKrdXH50Xg=; Received: (qmail 26094 invoked by alias); 15 Feb 2012 00:41:33 -0000 Received: (qmail 26086 invoked by uid 22791); 15 Feb 2012 00:41:32 -0000 X-SWARE-Spam-Status: No, hits=-1.6 required=5.0 tests=AWL, BAYES_00, FROM_12LTRDOM X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 15 Feb 2012 00:41:17 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1RxSvs-0002JI-3m from Bernd_Schmidt@mentor.com for gcc-patches@gcc.gnu.org; Tue, 14 Feb 2012 16:41:16 -0800 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Feb 2012 16:40:41 -0800 Received: from [127.0.0.1] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Wed, 15 Feb 2012 00:41:12 +0000 Message-ID: <4F3AFF25.9010208@codesourcery.com> Date: Wed, 15 Feb 2012 01:41:09 +0100 From: Bernd Schmidt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.20) Gecko/20110920 Lightning/1.0b3pre Thunderbird/3.1.12 MIME-Version: 1.0 To: GCC Patches Subject: C6X: Fix floating point scheduling scheduling bug Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org We have code in the backend to predicate instructions with long delays while scheduling, so that they can be placed in jump delay slots. For example, [a1] b label nop 3 ldw *a2, a0 ;; this insn is from the basic block after the branch nop ;; branch occurs here is not safe even if A0 is not used at the branch target, since the load will place data into A0 after the branch occurs, and we don't know whether that conflicts with the code there. We can make this safe by changing it into [a1] b label nop 3 [!a1] ldw *a2, a0 nop ;; branch occurs here since we know we're scheduling extended basic blocks, so we control the code in the fallthru path. This all works except for certain floating point instructions, which not only store their destination after a given number of cycles, but which also reserve functional units for multiple cycles. In the testcase I have, it's a CMPLTDP instruction which can't be allowed to be placed in the last delay cycle of the branch, since it reserves its units for two cycles. Fixed with this patch. Committed. Bernd * config/c6x/c6x.md (reserve_cycles): New attribute. * config/c6x/c6x.c (c6x_sched_reorder_1): Ensure insns we predicate don't reserve functional units after the branch occurs. Index: gcc/config/c6x/c6x.c =================================================================== --- gcc/config/c6x/c6x.c (revision 184237) +++ gcc/config/c6x/c6x.c (working copy) @@ -4196,13 +4196,14 @@ c6x_sched_reorder_1 (rtx *ready, int *pn bool is_asm = (icode < 0 && (GET_CODE (PATTERN (insn)) == ASM_INPUT || asm_noperands (PATTERN (insn)) >= 0)); - int this_cycles; + int this_cycles, rsrv_cycles; enum attr_type type; gcc_assert (!is_asm); if (icode < 0) continue; this_cycles = get_attr_cycles (insn); + rsrv_cycles = get_attr_reserve_cycles (insn); type = get_attr_type (insn); /* Treat branches specially; there is also a hazard if two jumps end at the same cycle. */ @@ -4211,6 +4212,7 @@ c6x_sched_reorder_1 (rtx *ready, int *pn if (clock_var + this_cycles <= first_cycle) continue; if ((first_jump > 0 && clock_var + this_cycles > second_cycle) + || clock_var + rsrv_cycles > first_cycle || !predicate_insn (insn, first_cond, false)) { memmove (ready + 1, ready, (insnp - ready) * sizeof (rtx)); Index: gcc/config/c6x/c6x.md =================================================================== --- gcc/config/c6x/c6x.md (revision 184237) +++ gcc/config/c6x/c6x.md (working copy) @@ -201,6 +201,17 @@ (define_attr "cycles" "" (eq_attr "type" "mpysp2dp") (const_int 5)] (const_int 1))) +;; The number of cycles during which the instruction reserves functional +;; units. +(define_attr "reserve_cycles" "" + (cond [(eq_attr "type" "cmpdp") (const_int 2) + (eq_attr "type" "adddp") (const_int 2) + (eq_attr "type" "mpydp") (const_int 4) + (eq_attr "type" "mpyi") (const_int 4) + (eq_attr "type" "mpyid") (const_int 4) + (eq_attr "type" "mpyspdp") (const_int 2)] + (const_int 1))) + (define_attr "predicable" "no,yes" (const_string "yes"))