From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) by sourceware.org (Postfix) with ESMTPS id 419EE3857C41 for ; Tue, 23 Aug 2022 02:01:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 419EE3857C41 Received: by mail-qt1-x82f.google.com with SMTP id r6so329798qtx.6 for ; Mon, 22 Aug 2022 19:01:10 -0700 (PDT) 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=FN/FpNP7SidS3ojhoFPKC2XgNA1o+Nr3JqMw2QSqgZM=; b=jAACoNwxTD9bHP/4jM2uHjsC/fWOfshZWDyP7WE1wLh3jHDNMlTsXKYGOSzcw1Fl+6 LRAv6b+wV9iMMtGwpGgsXkdsoqkiyY33wb24Hl0D1H8UT/3izax3gHKxyCV2yh25KUVR TXHyw8134S2//TeZq1RBRr9WXNkDex51L1zCsjKKgmuHW0VqkrpGAwmSuum49sPq+IFp MnF94xoI2e66nYAyGJIzyXc5GbXbQo2tij6Lnp7OvnOqUfV5bpfT1xqfSEsX5PrZWMuN LrCe/8DY5Y2SeCokdpI589vTW9EsTneSIkd3fNeW+Nf/F0qwIka/TuCkABm5gFbaGzDB lQiA== X-Gm-Message-State: ACgBeo3yDrr5t+N1Sx8U8fV92aQNDua3NkXs+zvC8y0PALDLBgb706KZ Pt/ZMM4JOuLgEA/2F7JJI2o8deMu/0gCxp0HfjFCztSy X-Google-Smtp-Source: AA6agR7SASPyXTgjGI2lMpZnygvZhH/DeHz5HpehfKFpLWPuZr/vDLLGzJHepmyu457Rfci/Rvs4jbu5ffSzIQgln5M= X-Received: by 2002:a05:622a:205:b0:343:282:3d0e with SMTP id b5-20020a05622a020500b0034302823d0emr17777620qtx.436.1661220069527; Mon, 22 Aug 2022 19:01:09 -0700 (PDT) MIME-Version: 1.0 References: <32216291-fd1f-4579-87de-d24cb7190894@suse.com> <995353db-27f3-ea60-8e69-32bcc44dfd49@suse.com> In-Reply-To: From: "H.J. Lu" Date: Mon, 22 Aug 2022 19:00:33 -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, 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 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: Tue, 23 Aug 2022 02:01:11 -0000 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. > >> 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. > ... here will continue to be the case with those later changes. > > Jan -- H.J.