From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) by sourceware.org (Postfix) with ESMTPS id 622A6385117C for ; Fri, 26 Aug 2022 18:47:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 622A6385117C 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-x830.google.com with SMTP id cr9so1903138qtb.13 for ; Fri, 26 Aug 2022 11:47:01 -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; bh=gdPDx8ziNLkPApqyoLroxOpMQlbhUBXP2z85PJ7AKFY=; b=Wza22imp3uv7MqC7fdElBe+RG+mTlXupVd5YutOsmTMTdd7LRTJF1VJ0ZHBvBdbc2d JvRTwgxDFuC60WhX+j7TkjN/fcSsoK0h3QSSqu9RSv7azhJdKLUqFmCxiplxUe/nItrw aJX+1x56CovKiqEeuT85wqepO5laBNELBc4bD/EA0yw1g/ie3OaJ7h5jj+IBPYzjuYt2 VWmYqJ3WwDMnFZcskv6F8/pfqxZyH2OumHKv4TveI231LzVUOlWGPR9AZ3bMqj186Am3 oxZUVYIwjAAFmSwGzKmRaWcxafRwqxHgmHdsqes8cQKx2e3HFO4iYqnEbiuSfpr6rJph 5/Gg== 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; bh=gdPDx8ziNLkPApqyoLroxOpMQlbhUBXP2z85PJ7AKFY=; b=5IND8/E3AInthHtqfoMUihetPvrmnKDc/62MDavJzRf/6PLyprFfzu8zc5FtujsywG J/2CQ5YRh+EGRfOcpBC/eCexV/LP2IhP9TuksLQRnZduFF/QMnEvftA2C7sV+1viyGS+ Sjg0ufyoNGmA/zMDQGrkmspU2laXIfTXDAo6vHivOIDbf30HSHPJ3Y7f6tUgkDntjE9L PHL0GnN6RvZ+ThtHM/lQDnqXEL1kktBEsfCdpxL2T52KDUbYZD2bgH3LuwlT2LLrxKMO IVqFu2i2TuCXFjyXMDzi3kfrGDSj14JS3haUfGL5MRe20DbIejCq2eFzG6ko1gBVR/2p fmvA== X-Gm-Message-State: ACgBeo1gLeCG7dkHKhgdPD6toxFNbzR8nF/9VDckS0Idv5FdiRSU5b/P KxQmCA2TRfv4bdjJNz9BXOn6EGlL5uJrrnjOWOU= X-Google-Smtp-Source: AA6agR5vDzQPTTTCtF2zJ0JiihQbf7V7wiPs2D1hj/qV01Z4899/nvz/fNWB3/ldJr/VBY7reFbC+JzK/Pbq/2chL+Q= X-Received: by 2002:a05:622a:44c:b0:343:7b8e:2cb with SMTP id o12-20020a05622a044c00b003437b8e02cbmr857792qtx.617.1661539620613; Fri, 26 Aug 2022 11:47:00 -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: <162c053b-7c68-67b8-1443-926f2ebb321d@suse.com> From: "H.J. Lu" Date: Fri, 26 Aug 2022 11:46:25 -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=-3018.9 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 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. > In any event, I'll be shortly submitting v2 of the series addressing > these. > > >>>> Further this sets the stage for the subsequent two changes, which I > >>>> don't think are easily possible without this 2nd pass. > >>> > >>> Does it indicate that the second pass is used quite often? > >> > >> No, what I did say ... > >> > >>>> And finally you've likely spotted that this is actually a reduction in > >>>> code size, first and foremost because the odd maybe_adjust_templates() > >>>> can now go away. Plus I think you realize that the 2nd pass wouldn't > >>>> be engaged in many cases - it requires a template match failure in the > >>>> 1st pass, after all, which isn't going to happen very often. > > > > There is a fixed cost to prepare for the second pass. > > A very limited one (I suppose there are enough other things which are > more of an overhead). Plus part of the preparation happens only when > the first pass didn't find any match. > > Jan -- H.J.