From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104557 invoked by alias); 8 Jan 2018 11:57:47 -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 104547 invoked by uid 89); 8 Jan 2018 11:57:46 -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-f195.google.com Received: from mail-ot0-f195.google.com (HELO mail-ot0-f195.google.com) (74.125.82.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 08 Jan 2018 11:57:45 +0000 Received: by mail-ot0-f195.google.com with SMTP id 37so8989196otv.6 for ; Mon, 08 Jan 2018 03:57:45 -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=uXXGfwsBqaWQZJQ2gwJM53mFye0zc6dGfUMIwBYAY+8=; b=fdeVe3c7t5JFmBwDDU5SEUdukPNqGDTPX6xRcfeJL3tVP5HlZlzedMPnAowBbGQVZj wKjDzkuqWbE/v6zHckQF3HZFzQc2xhPlLvEtsj+h3fRfUwk5J+iHGRM3r78I+rtZde4y MSTXwd3tcDLCmQHYktc2HC+I7ZbAslUXEWDtZ15I1b2YNAs2XnfuiVGWJNKA+Qxb+/ck MpYSTs3o8OQjUyqcSvn+F4q+4BRqBkq2sKn1wZeMTAYQ0XGBH7L/ZAXDUyUQVCAhGNzC IhTtAekV2z7dcuybym5p+LNqMF1veDrn3Q2W3xiP96rT2mNPJCV4VkKMFnbn4HzuoiZb CV7w== X-Gm-Message-State: AKwxytegbIis5umQ7ficRGUIoVTox9T8CU2q/q0B8JLgL1Z9Si/eZZT+ KYmUUp6SQvyUywgHKrZ/8L7T3xXr8pEBYuK5oE8= X-Google-Smtp-Source: ACJfBou+jauShHPYlswS3hj0bi7f+izmjpwJWo5/sn0wyF4YD0qGdi2MSe9XlFZIsa+/bDghcIcrjhsYxSN152DlIlk= X-Received: by 10.157.37.55 with SMTP id k52mr6526844otb.392.1515412663501; Mon, 08 Jan 2018 03:57:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.151.42 with HTTP; Mon, 8 Jan 2018 03:57:43 -0800 (PST) In-Reply-To: <5A536A0E020000780019C242@prv-mh.provo.novell.com> References: <20180108011834.GA9768@gmail.com> <5A533E7B020000780019BFDD@prv-mh.provo.novell.com> <5A5365AB020000780019C1FF@prv-mh.provo.novell.com> <5A536A0E020000780019C242@prv-mh.provo.novell.com> From: "H.J. Lu" Date: Mon, 08 Jan 2018 11:57: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/msg00072.txt.bz2 On Mon, Jan 8, 2018 at 3:54 AM, Jan Beulich wrote: >>>> On 08.01.18 at 12:48, wrote: >> On Mon, Jan 8, 2018 at 3:35 AM, Jan Beulich wrote: >>>>>> On 08.01.18 at 12:22, wrote: >>>> On Mon, Jan 8, 2018 at 3:14 AM, H.J. Lu wrote: >>>>> 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? >>> >>> Hopefully later this week. >>> >>>> If we do that, should we also remove MOVD with 64-bit memory? >>> >>> We can't, as even up-to-date AMD PM still specifies this name >>> instead of MOVQ. >> >> I consider it is a defect in AMD manual. >> >>>> Otherwise, -msse2avx won't work on MOVD with 64-bit memory. >>> >>> Hmm, good point - perhaps the SSE2AVX pattern then needs the >>> change that you've been doing, while the plain one could have its >>> memory alternative removed? >> >> If we can't remove MOVD with 64-bit memory, I will go with my patch. > > Fine with me for the AVX variant, but please consider dropping > the AVX512 one. Did you mean dropping AVX512 vmovd with 64-bit memory operand? -- H.J.