From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121749 invoked by alias); 14 Feb 2020 13:50:38 -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 121741 invoked by uid 89); 14 Feb 2020 13:50:37 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*f:sk:357d944, H*i:sk:357d944, HX-Spam-Relays-External:209.85.167.196, H*RU:209.85.167.196 X-HELO: mail-oi1-f196.google.com Received: from mail-oi1-f196.google.com (HELO mail-oi1-f196.google.com) (209.85.167.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 14 Feb 2020 13:50:35 +0000 Received: by mail-oi1-f196.google.com with SMTP id q81so9477146oig.0 for ; Fri, 14 Feb 2020 05:50:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=w2A6BRcKHpIFMZ6tLXnEkveXdb4vkdxsS334BcKuXvo=; b=q3QLXPDkbcKazzlbU6Zz+djkrO0cdm5Qdm5nekzpITXaxaaMwInbuIQvVfViQPVT4j FSS+tcoJrdsZVYYcn+gsLqhyG5zry/nkKWLPHWhhIE+TTHCXkgfpR4262K6sC7p1b9hc 1ScdzDJpet88gU2AaXrlxNGmuCZTh/j0hcCkTWb88UubK1jPXgw2S7hcuCX3JZ7b4EA4 L/715vocZdI957kADIN+1Kpemx1P36urxCoY6KJXAD+VR7Cmd1sa227+9W+LANiWMTQZ wHh4CpNMHSCg7xy3zq7/LHK0Hwb/B5suvwKSQU+M1VTzqqCuBqiqtGLfz9aSGMzMZMFd ZtNA== MIME-Version: 1.0 References: <357d9440-985a-7aaa-1816-7dcc0c33461d@suse.com> In-Reply-To: <357d9440-985a-7aaa-1816-7dcc0c33461d@suse.com> From: "H.J. Lu" Date: Fri, 14 Feb 2020 13:50:00 -0000 Message-ID: Subject: Re: [PATCH] x86: fold certain VCVT{,U}SI2S{S,D} templates To: Jan Beulich Cc: "binutils@sourceware.org" Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00351.txt.bz2 On Fri, Feb 14, 2020 at 5:41 AM Jan Beulich wrote: > > There don't really need to be separate Cpu64 and CpuNo64 templates for > these. One small issue with this is that slightly strange code > > .intel_syntax noprefix > .code16 > .arch i286 > .arch .avx > vcvtsi2sd xmm0, xmm0, dword ptr [bx] > vcvtsi2sd xmm0, xmm0, qword ptr [bx] > > vcvtsi2sd xmm0, xmm0, ebx > vcvtsi2sd xmm0, xmm0, rbx > > now will match in behavior with the AVX512 counterparts in that not > only the 2nd vcvtsi2sd won't assemble, but also the first. The last > two, otoh, will continue to assemble fine (due to the lack of any > memory operand size specifier). As a result, another way to make > things behave more consistently would be to avoid the folding and > add IgnoreSize to the CpuNo64 AVX512 variants. A 3rd way to do so > would be to add Cpu386 to any such insn template. > > While doing this also make the usual cosmetic adjustments for the > insns touched anyway. Additionally drop the redundant Cpu64 from > the SAE forms of VCVT{,U}SI2SD - they won't assemble outside of > 64-bit mode due to there not being anything to match the Reg64 > operand. > > opcodes/ > 2020-02-XX Jan Beulich > > * i386-opc.tbl (vcvtsi2sd, vcvtsi2ss, vcvtusi2sd, vcvtusi2ss): > Fold CpuNo64 and Cpu64 templates. Use VexLIG/EVexLIG and VexW0/ > VexW1 instead of open-coding them. > * i386-tbl.h: Re-generate. > OK. Thanks. -- H.J.