From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29019 invoked by alias); 26 Feb 2011 10:04:57 -0000 Received: (qmail 29009 invoked by uid 22791); 26 Feb 2011 10:04:55 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-wy0-f169.google.com (HELO mail-wy0-f169.google.com) (74.125.82.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 26 Feb 2011 10:04:51 +0000 Received: by wyi11 with SMTP id 11so2806078wyi.0 for ; Sat, 26 Feb 2011 02:04:49 -0800 (PST) Received: by 10.227.10.74 with SMTP id o10mr3002316wbo.229.1298714688920; Sat, 26 Feb 2011 02:04:48 -0800 (PST) Received: from localhost (rsandifo.gotadsl.co.uk [82.133.89.107]) by mx.google.com with ESMTPS id o6sm1364855wbo.3.2011.02.26.02.04.46 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 26 Feb 2011 02:04:48 -0800 (PST) From: Richard Sandiford To: "Maciej W. Rozycki" Mail-Followup-To: "Maciej W. Rozycki" ,binutils@sourceware.org, rdsandiford@googlemail.com Cc: binutils@sourceware.org Subject: Re: [PATCH] MIPS/GAS: Clean-up no-delay slot instruction annotation References: Date: Sat, 26 Feb 2011 10:04:00 -0000 In-Reply-To: (Maciej W. Rozycki's message of "Fri, 25 Feb 2011 20:55:09 +0000 (GMT)") Message-ID: <878vx3qfgi.fsf@firetop.home> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2011-02/txt/msg00363.txt.bz2 "Maciej W. Rozycki" writes: > The MIPS architecture defines a set of instructions that are not allowed > to be placed in a branch delay slot or unpredictable behaviour will > happen. Additionally GAS deliberately does not reorder some other > instructions that are actually allowed in a branch delay slot, but their > intent is to trigger an exception under some circumstances and handling > such an exception, although architecturally supported, is sometimes > problematic if coming from a branch delay slot. > > Currently we do not distinguish between the two cases and furthermore we > correctly annotate some instructions to keep them out of delay slots, we > annotate some instructions unnecessarily, and we fail to annotate some, > which we handle by checking their opcodes explicitly. Ah, and we have > this honourable SYNC instruction that got awarded with its own flag for > this very purpose. > > I believe this all is unnecessary. We can do with a single flag, if set > correctly for all the affected instructions, and no explicit opcode > checks. Here's a change that implements my idea. I have renamed the > INSN_TRAP flag to INSN_NO_DELAY_SLOT, to reflect its meaning more > accurately. I have kept the TRAP alias though for instructions that GAS > deliberately chooses not to schedule into delay slots even they are > otherwise permitted there. I have added a new alias, NODS, for these > instructions that are truly forbidden there to make it easy to distinguish > between the two classes. I have used the new flag for SYNC, the ERET and > DERET instructions that were checked explicitly and lacked any annotation, > and updated all the other instructions of this kind including, but not > limited to MIPS16 compact jumps. I haven't added this flag to branches > that are already excluded implicitly by means of some obscure conditions > (like being relaxed or having a fixup attached); though frankly perhaps we > should use this flag on them too, to make it explicit they cannot be > scheduled into delay slots. WDYT? By including INSN_NO_DELAY_SLOT in UBD, etc? Sounds like a good idea. I like the way you've kept the TRAP vs. NODS distinction in the opcode tables, so that the short macros give semantic information, and the #defines map that information to flags. On that basis, if property X inherently stops the instruction being placed in a delay slot, it seems better to include INSN_NO_DELAY_SLOT in the #define for X than to add "|NODS" to each X entry. Richard