From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) by sourceware.org (Postfix) with ESMTPS id 827833858D39 for ; Thu, 29 Sep 2022 16:21:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 827833858D39 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-qv1-xf30.google.com with SMTP id c15so1210639qvp.7 for ; Thu, 29 Sep 2022 09:21:22 -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=xKT2N6Q+pQh0zSE9A1AfhkrNRlZSz1rKW3muk7DZGEs=; b=AenhPvzks/bgSnZvW3/KwHgAVJdgjkAhpH0cq4NNHsrBdPepn23uJqKYSev508Qamm ffRy9WQjcP4qKdsm7Rwmyk599x/vAC8v5AWfEIPP/nR0rIZGeKvE6a2FXqOK/wiwRmbG t7mLVHu1P16IIt/G7tVONe46VhRnNkKqIkUCHHihc2ayWSbFy+rhyjNK9bac0eCJKbnh rc+NZUZV7I9Rhc/UefbafET3m8/cS8o5yx8wLLsCUssihDKlzotGPgCHlmfhevDF9sZt N/L/G4a7wGMHtMScSpzaZv60+y98q/qrV3g7XltEQkHis3o+JVczgNYEBy66Vi6c82ZN UbzA== 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=xKT2N6Q+pQh0zSE9A1AfhkrNRlZSz1rKW3muk7DZGEs=; b=mNQ8OwNkeGG8p4tE5BEOA8DjCrtrVEg+MTjLzVq38rK7G41sSlKSsuxIQ/VQAN9wve yCo5xi01+tD/IoxaEyaZCdSw2hWCbNffoJPzXcQXbu1bK00dudBx7Mip3qI4MC6hArbs mZfcpcUb7f2IBofRYkn/y0jxod/2GIq74vcBFmSc9AwP0BU1XngCtLv958qUnbIt5TEB t43ae571dpna3OnHcjUNV5sh6CUzuDoIqttVUszANmW8qAqOn9LpIc3ezcPX/qJKq5VB BhQp0N3AgJ7jX7OoIy1pIoTwWw0CAkBdfX+hmFnGE3u7JdV6AHTh+ErkPPkJgUOmMxBD m/QQ== X-Gm-Message-State: ACrzQf3PwUjQHkpi0AljUCokEm3wzOv27ieLRfxn7IME+KWnSAK5Bbjk PfgUJGiH91gh+pZQpgl9azo1WRy19Uplvz1XZ00= X-Google-Smtp-Source: AMsMyM5Onb/3/sfIYuYC7K/LAZ7MgriWuzdDQFKUqfcqW3wF7sFZRYQhgetNdUwOFGZD27PIPl0R6yfIdk4R/B2Gtds= X-Received: by 2002:a05:6214:d0e:b0:4ad:5e35:329a with SMTP id 14-20020a0562140d0e00b004ad5e35329amr3318201qvh.28.1664468481814; Thu, 29 Sep 2022 09:21:21 -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> <892afda8-0e6a-cc7c-df95-f5581e831fff@suse.com> <93622263-1a05-07e7-4a96-c33cffb0796b@suse.com> In-Reply-To: From: "H.J. Lu" Date: Thu, 29 Sep 2022 09:20:45 -0700 Message-ID: Subject: Re: [PATCH 5/7] x86: re-work insn/suffix recognition To: Jan Beulich Cc: Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3017.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.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, Sep 29, 2022 at 9:06 AM Jan Beulich wrote: > > On 29.09.2022 18:00, H.J. Lu wrote: > > On Thu, Sep 29, 2022 at 1:08 AM Jan Beulich wrote: > >> > >> On 28.09.2022 21:33, H.J. Lu wrote: > >>> On Wed, Sep 28, 2022 at 5:49 AM Jan Beulich wrote: > >>>> I guess to prove (and going forward guarantee) the apparent behavior of > >>>> parse_insn() I'd like to constify its first parameter. This might > >>>> involve adding a cast (to drop const-ness again after the call), which > >>>> I generally would like to avoid, or some "interesting" pointer > >>>> arithmetic. If you have any opinion here up front, please let me know. > >>> > >>> Can we avoid it by adding some new entries to the opcode table? > >>> I don't think we need many such entries. > >> > >> I'm afraid I don't see the connection between the intended constification > >> and what entries there are (or not) in the opcode table. I view it as a > >> desirable property of the function in the first place to express its > >> behavior (of not altering the input string) by a pointer-to-const > >> parameter. In fact I guess I would make such an adjustment a standalone > >> (prereq for the larger change) patch. > >> > > > > Rescan means that the first scan fails. Can we add new entries which only > > do the second scan? > > Why would we add such redundant entries? All that could happen is them > going out of sync with their counterparts processable on the 1st pass. > The overall goal has been to reduce redundancy and hence the risk of > inconsistencies. > These new entries should be rare and only for existing instructions. We won't add more of them. -- H.J.