From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12345 invoked by alias); 25 Sep 2012 08:07:34 -0000 Received: (qmail 12327 invoked by uid 22791); 25 Sep 2012 08:07:31 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-ey0-f175.google.com (HELO mail-ey0-f175.google.com) (209.85.215.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 25 Sep 2012 08:07:18 +0000 Received: by eaac1 with SMTP id c1so423516eaa.20 for ; Tue, 25 Sep 2012 01:07:17 -0700 (PDT) Received: by 10.14.224.73 with SMTP id w49mr17676272eep.37.1348560437256; Tue, 25 Sep 2012 01:07:17 -0700 (PDT) Received: from localhost ([2.26.188.227]) by mx.google.com with ESMTPS id m42sm50208558eep.16.2012.09.25.01.07.15 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 25 Sep 2012 01:07:16 -0700 (PDT) From: Richard Sandiford To: "Maciej W. Rozycki" Mail-Followup-To: "Maciej W. Rozycki" ,Sandra Loosemore , , rdsandiford@googlemail.com Cc: Sandra Loosemore , Subject: Re: PING Re: [PATCH, MIPS] add new peephole for 74k dspr2 References: <502D0DF4.3070302@codesourcery.com> <87zk5qu783.fsf@talisman.home> <5034EBC6.5080602@codesourcery.com> <87bohw1ecb.fsf@talisman.home> <5058ACDA.5060706@codesourcery.com> <87lig719ig.fsf@talisman.home> <87sja7tadr.fsf@talisman.home> Date: Tue, 25 Sep 2012 08:38:00 -0000 In-Reply-To: (Maciej W. Rozycki's message of "Mon, 24 Sep 2012 23:09:49 +0100") Message-ID: <87obkuttj6.fsf@talisman.home> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2012-09/txt/msg01689.txt.bz2 "Maciej W. Rozycki" writes: > On Mon, 24 Sep 2012, Richard Sandiford wrote: > >> > From the context I am assuming none of this matters for the 74K (and >> > presumably the 24KE/34K) and a MULT $0, $0 is indeed faster, but overall >> > isn't it something that should be decided based on instruction costs from >> > DFA schedulers? Is there anything that I've missed here? It doesn't >> > appear to me your (and neither the original) proposal takes instruction >> > cost calculation into consideration. >> >> In practice, we only move 0 into HI and LO for MADD- and MSUB-style >> operations. We deliberately don't use HI and LO as scratch space. >> >> I think it's a reasonable default assumption that anything that supports >> those instructions also has a fast path from MULT to MADD or MULT to MSUB. > > According to my sources the R4650 has a 4-cycle MULT latency (MAD is 3-4 > cycles on that processor). An MTHI/MTLO pair will take 2 cycles; > obviously the resulting larger code may adversely affect cache performance > in some scenarios. That's not how the 4650 DFA models it though. (define_insn_reservation "generic_hilo" 1 (eq_attr "type" "mfhi,mflo,mthi,mtlo") "imuldiv*3") (define_insn_reservation "r4650_imul" 4 (and (eq_attr "cpu" "r4650") (eq_attr "type" "imul,imul3,imadd")) "imuldiv*4") So if we believed the DFA, MTLO + MTHI would occupy the muldiv unit for 6 rather than 4 cycles. Any attempt to use the DFA would still favour MULT. Richard