From patchwork Wed Jul 14 11:03:23 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jie Zhang X-Patchwork-Id: 58864 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 67490B6F14 for ; Wed, 14 Jul 2010 21:03:39 +1000 (EST) Received: (qmail 32719 invoked by alias); 14 Jul 2010 11:03:37 -0000 Received: (qmail 32617 invoked by uid 22791); 14 Jul 2010 11:03:36 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL, BAYES_00, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 14 Jul 2010 11:03:32 +0000 Received: (qmail 22920 invoked from network); 14 Jul 2010 11:03:30 -0000 Received: from unknown (HELO ?192.168.0.124?) (jie@127.0.0.2) by mail.codesourcery.com with ESMTPA; 14 Jul 2010 11:03:30 -0000 Message-ID: <4C3D997B.5080005@codesourcery.com> Date: Wed, 14 Jul 2010 19:03:23 +0800 From: Jie Zhang User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.4) Gecko/20100608 Lightning/1.0b2 Thunderbird/3.1 MIME-Version: 1.0 To: GCC Patches Subject: [ARM] Fix reservation cortex_a8_load_store_2 X-IsSubscribed: yes 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 I just found reservation cortex_a8_load_store_2 might not be correct. I think it should reserve cortex_a8_issue_ls in the second cycle. The patch is attached. I also add cortex_a8_issue_ls to the first cycle. So we can remove the comment on why we don't reserve cortex_a8_issue_ls. After the change, this reservation is not same as cortex_a8_multiply_2 any more. So I remove that comment, too. Tested it on arm-none-eabi for NEON. Is it OK? Regards, * config/arm/cortex-a8.md (cortex_a8_load_store_2): Reserve cortex_a8_issue_ls. Index: config/arm/cortex-a8.md =================================================================== --- config/arm/cortex-a8.md (revision 162168) +++ config/arm/cortex-a8.md (working copy) @@ -47,17 +47,15 @@ "(cortex_a8_alu0+cortex_a8_issue_ls)|\ (cortex_a8_alu1+cortex_a8_issue_ls)") -;; ...and in the case of two micro-ops. We don't need to reserve -;; cortex_a8_issue_ls here because dual issue is altogether forbidden +;; ...and in the case of two micro-ops. Dual issue is altogether forbidden ;; during the issue cycle of the first micro-op. (Instead of modelling ;; a separate issue unit, we instead reserve alu0 and alu1 to ;; prevent any other instructions from being issued upon that first cycle.) ;; Even though the load/store pipeline is usually available in either -;; ALU pipe, multi-cycle instructions always issue in pipeline 0. This -;; reservation is therefore the same as cortex_a8_multiply_2 below. +;; ALU pipe, multi-cycle instructions always issue in pipeline 0. (define_reservation "cortex_a8_load_store_2" - "cortex_a8_alu0+cortex_a8_alu1,\ - cortex_a8_alu0") + "cortex_a8_alu0+cortex_a8_alu1+cortex_a8_issue_ls,\ + cortex_a8_alu0+cortex_a8_issue_ls") ;; The flow of a single-cycle multiplication. (define_reservation "cortex_a8_multiply"