From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id 0059C3850419 for ; Wed, 24 Mar 2021 07:27:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0059C3850419 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 16C95AC6E; Wed, 24 Mar 2021 07:27:12 +0000 (UTC) Subject: Re: [PATCH 7/8] x86: derive mandatory prefix attribute from base opcode To: "H.J. Lu" Cc: Binutils References: From: Jan Beulich Message-ID: Date: Wed, 24 Mar 2021 08:27:11 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3033.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2021 07:27:14 -0000 On 23.03.2021 19:34, H.J. Lu wrote: > On Tue, Mar 23, 2021 at 9:36 AM Jan Beulich wrote: >> >> On 22.03.2021 19:03, H.J. Lu wrote: >>> On Mon, Mar 22, 2021 at 05:46:14PM +0100, Jan Beulich wrote: >>>> Just like is already done for legacy encoded insns, record the mandatory >>>> prefix information in the respective opcode modifier field. Do this >>>> without changing the source table, but rather by deriving the values from >>>> their existing source representation. >>>> >>>> gas/ >>>> 2021-03-XX Jan Beulich >>>> >>>> * config/tc-i386.c (md_begin): Add assertion. >>>> (build_vex_prefix): Drop implied prefix calculation. >>>> (build_evex_prefix): Likewise. >>>> (optimize_encoding): Adjust opcode checks. >>>> (load_insn_p): Also check opcodeprefix. >>>> (match_template): Also check opcodespace. >>>> (process_suffix): Likewise. >>>> (process_operands): Likewise. >>>> (output_insn): Likewise. Also check isprefix when discaring >>>> standalone LOCK. >>>> * config/tc-i386-intel.c (i386_intel_operand): Also check >>>> opcodespace. >>>> >>>> opcodes/ >>>> 2021-03-XX Jan Beulich >>>> >>>> * i386-gen.c (process_i386_opcode_modifier): Return void. New >>>> parameter "prefix". Drop local variable "regular_encoding". >>>> Record prefix setting / check for consistency. >>>> (output_i386_opcode): Parse opcode_length and base_opcode >>>> earlier. Derive prefix encoding. Drop no longer applicable >>>> consistency checking. Adjust process_i386_opcode_modifier() >>>> invocation. >>>> (process_i386_opcodes): Adjust process_i386_opcode_modifier() >>>> invocation. >>>> * i386-tbl.h: Re-generate. >>> >>> OK. Thanks. >> >> Thanks. Just to confirm - you being okay with the approach here, are >> also okay with the outlined (in a post commit message remark) further >> planned course of action? > > Sounds good to me. But I need to see the actual patch for sure. Well, there are multiple steps. The first one, to extract 0f etc "prefixes" from the opcodes, is less likely to be controversial. Reverting the PREFIX_0X uses on legacy encoded opcodes is likely to rank in the middle, while moving encoding space specification to the actual opcodes for VEX/XOP/EVEX templates is likely the most questionable one, not the least because of the need to "invent" a representation for XOP (I'm considering to use 8f0[89a] as a prefix, but I can also see alternatives). Jan