From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 60919 invoked by alias); 8 Jan 2018 11:14:35 -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 60882 invoked by uid 89); 8 Jan 2018 11:14:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-ot0-f175.google.com Received: from mail-ot0-f175.google.com (HELO mail-ot0-f175.google.com) (74.125.82.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 08 Jan 2018 11:14:33 +0000 Received: by mail-ot0-f175.google.com with SMTP id p16so6278212otf.1 for ; Mon, 08 Jan 2018 03:14:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DiFsBT+bXGjEGgUPBSAGxfmbjU+0kOW7GFGQE1ix7TQ=; b=CN7vwSUM8/L/xTGZLrzV8ZfpEzpKH0YxcgEpjWfOGOVkswdIjdzbCsfQbIkPv94Xug 516kL2b18lOdkbAGSFdoxQqlq7gTMS9OJLACSnatyBJHf4tZNsUkklBh9Ob8iAEgtsQd uS/eFg6C2syBhWRBmJ5iLGTJgQkZnB91Muc+dj8yf0MQ5lW07iLSeQeSZYspimEirLnW ttfKDhoi4Z/83v58pRkVgyB/D8cUJSRAFwfGjqSqNJ5l8g5If87q5ptTKIkxOSELYQe/ 4tnN+0ciIb4o30LfJrLJlqAiibLFefpmoxquwvE8FRDoIi9l3sSj0Xrg8CDCGCpfxgg7 OjPA== X-Gm-Message-State: AKwxyte3DRtnHd/yk8LJmlSeFCDeDdkbkCNeO0EMkxTpXcmIWjsbRcbI 79ucymaDdKv8cF6fti7qXUo319/mFsZ3Pfad/Ss= X-Google-Smtp-Source: ACJfBosT0lWbpxVcQlwyZPfkGxTKkKoCplL50xIp+83XxXkxNfgMMHtscs/f/F4JazgKYDEu1QxFC1v/x8JqfP6mwvk= X-Received: by 10.157.50.162 with SMTP id u31mr6212996otb.372.1515410071379; Mon, 08 Jan 2018 03:14:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.151.42 with HTTP; Mon, 8 Jan 2018 03:14:30 -0800 (PST) In-Reply-To: <5A533E7B020000780019BFDD@prv-mh.provo.novell.com> References: <20180108011834.GA9768@gmail.com> <5A533E7B020000780019BFDD@prv-mh.provo.novell.com> From: "H.J. Lu" Date: Mon, 08 Jan 2018 11:14:00 -0000 Message-ID: Subject: Re: [PATCH] x86: Properly encode vmovd with 64-bit memeory To: Jan Beulich Cc: Binutils Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-01/txt/msg00063.txt.bz2 On Mon, Jan 8, 2018 at 12:48 AM, Jan Beulich wrote: >>>> On 08.01.18 at 02:18, wrote: >> For historical reason, we allow movd/vmovd with 64-bit register and >> memeory operands. But for vmovd, we failed to handle 64-bit memeory >> operand. This has been gone unnoticed since AT&T syntax always treats >> memory operand as 32-bit memory. This patch properly encodes vmovd >> with 64-bit memeory operands. > > Interesting coincidence - just over the weekend I've run into this > issue too. My intended solution is quite different, though: Since > VMOVD (other than MOVD) doesn't have a 64-bit operand variant > in either Intel's SDM nor AMD's PM, I'd rather remove memory > operand support from it: > - generate code was wrong so far, so anyone having used it would > have run buggy code anyway, > - old gcc only ever uses the 64-bit variants with register operands. Works for me. Can you submit a patch? > Furthermore I think that the AVX512 64-bit variant should go away > altogether - it's register form is just a longer re-encoding of the > AVX form, and hence redundant, and gcc (afaics) doesn't use it. Shouln't vmovd with upper 32 xmm registers be encoded with AVX512? > One other oddity I've noticed in this context is the difference in > encoding choice between AVX and AVX512 VMOVQ with memory > operand: While the former uses the forms allowing for an XMM > register as alternative to the memory operand, the latter uses > the forms alternatively allowing for a GPR in 64-bit mode, and > the other one only in 32-bit mode. There's no comment there, so > I wonder whether this is intentional or an unnecessary > divergence. I prefer to leave it alone. Thanks. -- H.J.