From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47398 invoked by alias); 24 Feb 2017 09:31:59 -0000 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 Received: (qmail 47348 invoked by uid 89); 24 Feb 2017 09:31:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 spammy=H*f:sk:58AF183, H*MI:bYxazc, H*i:bYxazc, H*MI:sk:22CLvpg X-HELO: prv-mh.provo.novell.com Received: from prv-mh.provo.novell.com (HELO prv-mh.provo.novell.com) (137.65.248.74) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 24 Feb 2017 09:31:57 +0000 Received: from INET-PRV-MTA by prv-mh.provo.novell.com with Novell_GroupWise; Fri, 24 Feb 2017 02:31:55 -0700 Message-Id: <58B00AE1020000780013D81E@prv-mh.provo.novell.com> Date: Fri, 24 Feb 2017 09:31:00 -0000 From: "Jan Beulich" To: "H.J. Lu" Cc: "Binutils" Subject: Re: [PATCH v2] x86: fix handling of 64-bit operand size VPCMPESTR{I,M} References: <58AEE65B020000780013D38E@prv-mh.provo.novell.com> <58AF1834020000780013D540@prv-mh.provo.novell.com> In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SW-Source: 2017-02/txt/msg00323.txt.bz2 >>> On 23.02.17 at 17:20, wrote: > On Thu, Feb 23, 2017 at 8:13 AM, Jan Beulich wrote: >>>>> On 23.02.17 at 16:58, wrote: >>> On Thu, Feb 23, 2017 at 4:40 AM, Jan Beulich wrote: >>>> Just like REX.W affects operand size of the implicit rAX/rDX inputs to >>>> PCMPESTR{I,M}, VEX.W does for VPCMPESTR{I,M}. Allow Q or L suffixes on >>>> the instructions for AT&T mode. >>>> >>>> For Intel mode, however, suffixes aren't the preferred choice, so >>>> build_vex_prefix() needs to not only honor internally specified REX >>>> flags (converting them to their VEX equivalents), but also such >>>> resulting from explicit REX* prefix uses. Also adjust >>>> build_evex_prefix() for consistency. >>> >>> Please don't use EXISTING REX prefixes for this purpose. A new >>> prefix to control encoding is better, but it probably belongs to another >>> patch. >> >> I'm sorry, but I don't follow. If you want to go that route, we'll need >> more than just one new prefix, and it would be far from clear where >> to draw the boundary. Granted this would allow to address the >> 32-/16-bit side of things at once, but no, I don't think I have the >> time or energy to go that route (or else I would have done so right >> away, instead of adding a remark to the description in this regard). >=20 > We shouldn't change the meaning of existing REX prefixes. Let's > leave Intel mode alone for now. While I disagree, in the interest of getting the bug here fixed at least in some way, I've submitted v3 with the REX parts dropped. Jan