From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9936 invoked by alias); 14 Feb 2005 22:09:27 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 9662 invoked from network); 14 Feb 2005 22:09:09 -0000 Received: from unknown (HELO bluesmobile.specifixinc.com) (64.220.152.98) by sourceware.org with SMTP; 14 Feb 2005 22:09:09 -0000 Received: from [127.0.0.1] (bluesmobile.corp.specifixinc.com [192.168.1.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id 205DF16A06; Mon, 14 Feb 2005 14:09:09 -0800 (PST) Subject: Re: [PATCH] ia64: diagnostice for bad use of registers From: James E Wilson To: Jan Beulich Cc: binutils@sources.redhat.com In-Reply-To: References: Content-Type: text/plain Message-Id: <1108418949.7874.24.camel@aretha.corp.specifixinc.com> Mime-Version: 1.0 Date: Tue, 15 Feb 2005 03:31:00 -0000 Content-Transfer-Encoding: 7bit X-SW-Source: 2005-02/txt/msg00320.txt.bz2 On Thu, 2005-02-10 at 05:09, Jan Beulich wrote: > * config/tc-ia64.c (parse_operands): New local variables reg1, > reg2, > reg_class. Check operands and emit diagnostics for illegal use > of > registers. OK, but please add some comments describing the checks being performed, and the assumptions in the code. For instance, there are at most 2 output operands, except in the ldfp+update case, in which case there is no need to record the third update operand as it can't conflict with either of the first two operands. If we have two FP output operands, then we must have an ldfp instruction, so we perform the checks required by that instruction. Some of the checks destructively modify reg1, making them look like general registers, so we can not put any additional general register specific checks after this code. Or probably simpler, just use regno here instead of modifying reg1. It should be possible for someone to understand the patch even if they don't have your email message submitting the patch. While checking the manual, I noticed a somewhat special case that compares that set the same predicate register twice are invalid only if the qualifying predicate is true, or if they are an unc type compare. But since we can't check the qualifying predicate, it is reasonable to warn always. I doubt that anyone is deliberately using compares as nop instructions, and if they are, then the operands don't matter, and they can change them to valid ones. > (md_assemble): Defer resolution of move to/from application > registers > dynamic insns when they can be issued on either the I- or > M-units. This changelog entry is misplaced. This change is not part of this patch. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com