From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) by sourceware.org (Postfix) with ESMTPS id 656FA3858297 for ; Tue, 6 Sep 2022 21:53:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 656FA3858297 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-qt1-x835.google.com with SMTP id y18so9144792qtv.5 for ; Tue, 06 Sep 2022 14:53:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=2W4tIhTiDE1+wjTDuhIl31e5laJWvJEwhW4ejS9Y2GA=; b=igDxked/uDm3mOndroQr7D8gw3rcuGTlUfmFQXIEcoWhSxS7CmXNeS+yUXenFMqabl Qzhw9A6XJscvq8dR3y9JOHM6KLDOvYyX0nFe/PqWLlHELraX4uacfDyl71Q2b4txg+No 6QWbff8Tkgit+sLuySZ/WagNnpFpo5CNVpWLO4YOBJw28WF5K1dXZYOg+CvVzGWFMus0 9yKKaWCiBcRj0jGMCQa4St4cGRAI9Sxs6kFJuOukFKCOIsvf8LIQHNb8seieKX6ut/bV JbtznrLX6vrkIDerJs9Ca2DFBz6tVICDFpIJB9bliS2/0iIcOQIbtZ6iDp6cGkMOMw4F z3cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=2W4tIhTiDE1+wjTDuhIl31e5laJWvJEwhW4ejS9Y2GA=; b=kZSA00HcrGG4lxjZqFWMR/HF5zbsNqOu0GCgFZweuYtRujdxE0RQJZYdp9uouzp1+r smLDTN9cXpIN6sHuDeKXQ1t2/aVfKtBSo6OPmDIV+pNe6c2Kb2nVL7H/Q6rT0rNXv+Ar esurlF1EZmRQYSJ6VsHZApT0zbXlhUT5/bsgjlPoBENCDgvrBUmr7+mBTaEfMMrpEXkT BZod5O5TYA2cDwbIP6AJntbE0SWJBauf2Pt7b1LuGwf2KanbeZXsGLMVOQx5Wsa7cWGY wBTSPJqWEEfdJZ8O+HSxEYh5s52RrQo2fF8pQCKrCcvvj42ybK0KA24mBqTEwku+vy4x RLOg== X-Gm-Message-State: ACgBeo13xg4KVUhSPOuTvHw5Vw3h+Vomw2x5kiYHZMspQ4BnLQ7ydA0J sS3oS7fiz5STlR4hogpLhBjd+GiknJGmIkeefG8= X-Google-Smtp-Source: AA6agR7vegpekuQmm4nxMAxdklWkLS8T10Ol8aSmLE6Yf+u5nv0amb+Agbr4g9QZmw1vV+vmUvIoDmrkqb+VMPAGlw0= X-Received: by 2002:ac8:7c56:0:b0:344:24c1:60ff with SMTP id o22-20020ac87c56000000b0034424c160ffmr591097qtv.437.1662501223700; Tue, 06 Sep 2022 14:53:43 -0700 (PDT) MIME-Version: 1.0 References: <32216291-fd1f-4579-87de-d24cb7190894@suse.com> <995353db-27f3-ea60-8e69-32bcc44dfd49@suse.com> <162c053b-7c68-67b8-1443-926f2ebb321d@suse.com> In-Reply-To: From: "H.J. Lu" Date: Tue, 6 Sep 2022 14:53:07 -0700 Message-ID: Subject: Re: [PATCH 5/7] x86: re-work insn/suffix recognition To: Jan Beulich Cc: Binutils , Nick Clifton Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3018.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,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, Sep 5, 2022 at 11:40 PM Jan Beulich wrote: > > On 26.08.2022 20:46, H.J. Lu wrote: > > On Fri, Aug 26, 2022 at 2:26 AM Jan Beulich wrote: > >> > >> On 23.08.2022 04:00, H.J. Lu wrote: > >>> On Fri, Aug 19, 2022 at 1:28 AM Jan Beulich wrote: > >>>> > >>>> On 18.08.2022 17:14, H.J. Lu wrote: > >>>>> On Wed, Aug 17, 2022 at 11:24 PM Jan Beulich wrote: > >>>>>> > >>>>>> On 17.08.2022 22:29, H.J. Lu wrote: > >>>>>>> On Tue, Aug 16, 2022 at 12:32 AM Jan Beulich wrote: > >>>>>>>> > >>>>>>>> x86: re-work insn/suffix recognition > >>>>>>>> > >>>>>>>> Having templates with a suffix explicitly present has always been > >>>>>>>> quirky. Introduce a 2nd matching pass in case the 1st one couldn't find > >>>>>>> > >>>>>>> I don't like the second pass. What problem does it solve? > >>>>>> > >>>>>> It addresses the reasons we have various pretty odd (and confusing by > >>>>>> their mere presence) insn templates which better would never have been > >>>>>> there. If you have a better suggestion to eliminate those, I'm all ears. > >>>>>> > >>>>>> You can also easily see the issues this solves by looking at the > >>>>>> testsuite changes. Among other things this once again is a matter of > >>>>>> providing consistent and hence predictable behavior. > >>>>> > >>>>> Did you mean the error reporting behavior? I don't think we should add > >>>>> a second pass just for it. > >>>> > >>>> No. Certain insns simply were not accepted previously (this is actually > >>>> what finally made me think of a solution here; prior observations > >>>> weren't severe enough to try to get past your possible opposition which > >>>> was to be expected based on past discussions). And certain other ones > >>>> were wrongly accepted. > >>> > >>> Please open bug reports for these cases. > >> > >> PR gas/29524 > >> PR gas/29525 > >> PR gas/29526 > >> > >> But really - what's the point of making me waste time on creating bug > >> reports when fixes are already available? > > > > I don't see them as real issues and we shouldn't make assembler > > more complex because of them. > > I sincerely disagree. As said many times - first and foremost the assembler > should behave _consistently_. People should be able to predict behavior for > one insn by knowing what the behavior is for sufficiently similar insns, > without - as is the case twice here - having to further consider anomalies > resulting from _dissimilar_ insns. Assembler should be consistent with x86 SDM and the existing usage. Due to the history/nature of AT&T syntax and x86 instructions, there are existing inconsistencies. I don't think we should issue a warning for cmpsd. It is inconsistent with the 'd' suffix instead of 'l'. But it is consistent with SDM. What I'd like to see in mnemonics: 1. They are as close to SDM as possible. 2. Allow prefix when there is an ambiguity. 3. Intel syntax shouldn't depend on prefixes BTW, there is one inconsistency: https://sourceware.org/bugzilla/show_bug.cgi?id=29551 I'd like to resolve. > > I therefore also disagree with you having closed some of the entered bugs > as WONTFIX. I have to admit that I really wonder in how far binutils is an > open source project if (for x86) you alone take such decisions. > > Jan -- H.J.