From patchwork Tue Jun 11 16:27:05 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Moore, Catherine" X-Patchwork-Id: 250572 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]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "localhost", Issuer "www.qmailtoaster.com" (not verified)) by ozlabs.org (Postfix) with ESMTPS id 02F2E2C0097 for ; Wed, 12 Jun 2013 02:27:22 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:date:message-id:references:in-reply-to :content-type:content-transfer-encoding:mime-version; q=dns; s= default; b=JenZXm4avZg2UIuygbTBFx9cHwLSoNWeYihn+sIhoIg7abMqMqpHn joj96dD7C60eQeGqBvX2qtXm2r4HLiLMxRc/E4pijhBxVjDenva6RQoze7NUovPK kzPuZ3zJH9A+6cN2jWFmACOJy6TpCiDj7QA0TcBlCoT8rECA5XmZAk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:date:message-id:references:in-reply-to :content-type:content-transfer-encoding:mime-version; s=default; bh=ES0maxWXA0zBUMDVZSlg4dTfeGU=; b=p2CLld7YWNbCAY3Ggef6AWUeLmTe k2txKLEd4xeTgSNoh4vlwKNOqA7xOtymqHu/H4WIta7wBtRy0n4KdJtSEsAu3J6m 7QHjw3Ygy4kGIvhjkLGusL0YdeRxXyGZM+2Ai9sq+trKuZtvTjhLr4lYf1joUn6m haY9luGw5VcIG/U= Received: (qmail 31218 invoked by alias); 11 Jun 2013 16:27:16 -0000 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 Received: (qmail 31207 invoked by uid 89); 11 Jun 2013 16:27:16 -0000 X-Spam-SWARE-Status: No, score=-4.4 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, KHOP_THREADED, RCVD_IN_HOSTKARMA_W, RCVD_IN_HOSTKARMA_WL autolearn=ham version=3.3.1 Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 11 Jun 2013 16:27:09 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1UmRPX-0001tr-AD from Catherine_Moore@mentor.com ; Tue, 11 Jun 2013 09:27:07 -0700 Received: from SVR-ORW-FEM-03.mgc.mentorg.com ([147.34.97.39]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Jun 2013 09:27:06 -0700 Received: from NA-MBX-01.mgc.mentorg.com ([169.254.1.118]) by SVR-ORW-FEM-03.mgc.mentorg.com ([147.34.97.39]) with mapi id 14.02.0247.003; Tue, 11 Jun 2013 09:27:03 -0700 From: "Moore, Catherine" To: "Rozycki, Maciej" , Steve Ellcey CC: Richard Sandiford , "gcc-patches@gcc.gnu.org" , "Moore, Catherine" Subject: RE: [patch, mips] Micromips delay slot fix Date: Tue, 11 Jun 2013 16:27:05 +0000 Message-ID: References: <859b5b58-e3c6-44b5-ae35-a3515fa16a00@BAMAIL02.ba.imgtec.org> <1370908395.12204.234.camel@ubuntu-sellcey> In-Reply-To: MIME-Version: 1.0 > -----Original Message----- > From: Maciej W. Rozycki [mailto:macro@codesourcery.com] > Sent: Monday, June 10, 2013 8:50 PM > To: Steve Ellcey; Moore, Catherine > Cc: Richard Sandiford; gcc-patches@gcc.gnu.org > Subject: Re: [patch, mips] Micromips delay slot fix > > On Tue, 11 Jun 2013, Steve Ellcey wrote: > > > Sorry, it should have been 'main(void) {return 0; }. Then you get > > (with the patch): > > > > j $31 > > move $2,$0 > > > > instead of: > > > > move $2,$0 > > j $31 > > Hmm, something must have been missed then from the microMIPS patches > as our toolchain seems to get this case right: > > .set noreorder > .set nomacro > jr $31 > move $2,$0 > > .set macro > .set reorder > > (no idea where the extraneous newline comes from, hmm). Catherine, can > you please double-check you haven't got anything outstanding yet? There isn't anything outstanding. This is a bug in the mainline implementation due to the introduction of microMIPS instruction length calculations. In the original, all microMIPS insns had a length of 4. > > > > Is it safe to assume an RTL insn whose length is 4 has only a > > > single machine instruction in the microMIPS mode? What's the > > > difference to the > > > MIPS16 instruction set here? > > > > I think so, I don't know of any microMIPS RTL instructions whose > > length is 4 that would not be a single instruction. Maybe I should > > add Catherine in to the discussion to see if she knows differently. > > I advise care here, even if we currently have no such pattern. It's easy to > miss the dependency and any such bug introduced could trigger very rarely > only. Also (unlike with the standard ISA) some otherwise ordinary > instructions can't be scheduled into a delay slot, e.g. MOVEP or > LWP/LDP/SWP/SDP. > There are only a handful of microMIPS-specific instructions. They are single instructions, but they can't be placed in a delay slot. These instructions explicitly set the can_delay attribute to "no". I'm testing a slightly different patch from the one that Steve posted: Index: mips.md =================================================================== --- mips.md (revision 199648) +++ mips.md (working copy) @@ -703,8 +703,13 @@ ;; Is it a single instruction? (define_attr "single_insn" "no,yes" - (symbol_ref "(get_attr_length (insn) == (TARGET_MIPS16 ? 2 : 4) - ? SINGLE_INSN_YES : SINGLE_INSN_NO)")) + (if_then_else (ior (and (match_test "TARGET_MIPS16") + (match_test "get_attr_length (insn) == 2")) + (and (eq_attr "compression" "micromips,all") + (match_test "TARGET_MICROMIPS")) + (match_test "get_attr_length (insn) == 4")) + (const_string "yes") + (const_string "no"))) I'll let you know how it goes. Catherine