From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) by sourceware.org (Postfix) with ESMTPS id 1A8D33951C03 for ; Thu, 13 Jan 2022 13:52:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1A8D33951C03 Received: by mail-pl1-x62e.google.com with SMTP id h1so9954837pls.11 for ; Thu, 13 Jan 2022 05:52:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=36RMkS+6QTxptBBNGS0tvFE9SZSCfGyWg6j5c8/bwkE=; b=gWLQFvGwRk0XZ1YbUbMP3MhvswPchYfYy8r+UCIIp6Lf319fdcwTkvkdw54sB8XZ7L dnnLxQhUs9A2ocxDtYQQi7hV2XADOqfboMzNXIPLQZqfp+nKX65CSHzAuRbsVZJ4B6D/ kqndh5BYG4I4TXvWInxy6KQvCouy9L5XRM3RewqLKnfetLWtFE7J3plpwahUBZorR3qW b14k6nOnJtoN8CMrwYlxzQjxAj3JkaB38fGKsBXMZyZDdLjbM3UuCZKkBQZd4HBZDzda oZXcIHQXch9PtmSLtpt6/QVdb3MQ3IIELmb0CsXPzzwc4xJ6HHYbQZwGvpuegYrBNRe+ U71Q== X-Gm-Message-State: AOAM532JWxhWS8Dd7aNjmhyQKETEHnnqHYarulyzkKV4aH0D/np/KNlm Sa+Y2AGIUNkB1GB4cGOke8kfFgVYV6f4sVnxICWzdfvKwpk= X-Google-Smtp-Source: ABdhPJwdtiaP4ndjOE1EkfdRLAv5uNmhNMloFyNirK/cElwzFn+0pgU7I+rL/SBuIjFwX2/pcZDHf07j6rhVpTkQAsg= X-Received: by 2002:a63:3848:: with SMTP id h8mr3901679pgn.125.1642081949266; Thu, 13 Jan 2022 05:52:29 -0800 (PST) MIME-Version: 1.0 References: <2faa81af-20d9-01e9-0d2b-39422d40bc83@suse.com> <9b8863ec-b27d-e72e-2eb6-1db0e889ef88@suse.com> <68ecc032-db62-ac96-ee7d-89b7c5fcb5ab@suse.com> <638a6786-ff1f-ca47-b50c-3c0046b47f91@suse.com> In-Reply-To: From: "H.J. Lu" Date: Thu, 13 Jan 2022 05:51:53 -0800 Message-ID: Subject: Re: [PATCH 0/4] x86: opcode table tidying To: Jan Beulich Cc: Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3021.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Thu, 13 Jan 2022 13:52:31 -0000 On Thu, Jan 13, 2022 at 12:42 AM Jan Beulich wrote: > > On 06.01.2022 16:34, H.J. Lu wrote: > > On Thu, Jan 6, 2022 at 7:23 AM Jan Beulich wrote: > >> > >> On 06.01.2022 16:10, H.J. Lu wrote: > >>> On Thu, Jan 6, 2022 at 6:56 AM Jan Beulich wrote: > >>>> > >>>> On 06.01.2022 15:31, H.J. Lu wrote: > >>>>> On Thu, Jan 6, 2022 at 5:52 AM Jan Beulich wrote: > >>>>>> > >>>>>> On 06.01.2022 14:47, H.J. Lu wrote: > >>>>>>> On Thu, Jan 6, 2022 at 5:24 AM Jan Beulich wrote: > >>>>>>>> > >>>>>>>> On 05.01.2022 15:58, H.J. Lu wrote: > >>>>>>>>> On Wed, Jan 05, 2022 at 12:20:05PM +0100, Jan Beulich wrote: > >>>>>>>>>> 1: templatize FMA insn templates > >>>>>>>>>> 2: drop some "comm" template parameters > >>>>>>>>>> 3: drop NoAVX from POPCNT > >>>>>>>>>> 4: drop NoAVX insn attribute > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> OK for all. > >>>>>>>> > >>>>>>>> Thanks. I've committed the series, but I wonder whether you have an > >>>>>>>> opinion on the SSE4a aspect mentioned in the last patch. > >>>>>>> > >>>>>>> Do you have a patch? > >>>>>> > >>>>>> A patch to do what, exactly? (IOW: In order to perhaps make a patch, I > >>>>>> need to understand what the intentions are.) > >>>>> > >>>>> Please open a bug report to describe the issue. > >>>> > >>>> I guess I'll give up here. I can't know whether there's a bug without > >>>> knowing what the intentions are. Documentation also isn't sufficiently > >>>> clear / unambiguous. And I'm not willing to abuse bugzilla for having > >>>> a discussion; that's what I thought the mailing list is for. > >>> > >>> Are there any SSE instructions in SSE4a that aren't checked? > >> > >> Well, all of them are excluded from checking. There's even a test > >> for one of them checking that no diagnostic would be issued. > >> > >>> If yes, is it a bug? > >> > >> That's the question. What is unclear to me in particular is > >> - whether a diagnostic is to be issued only for insns which have > >> AVX equivalents (and hence can easily be replaced), > >> - whether the issue that we try to point out by the diagnostic > >> actually is applicable to any AMD CPU. > > > > Since they don't have AVX equivalents, I don't see a reason > > to check SSE4a. > > I've just realized that we've been here before, and things haven't since > been clarified towards a consistent view. See e.g. > > https://sourceware.org/pipermail/binutils/2020-June/111628.html > > and the containing thread. I continue to think that either documentation > or implementation need adjusting. We don't warn SSE instructions with MMX operands. I think SSE4a is similar. We can update documentation. Thanks. -- H.J.