From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) by sourceware.org (Postfix) with ESMTPS id D91683858CDB for ; Thu, 18 Aug 2022 15:15:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D91683858CDB Received: by mail-qv1-xf35.google.com with SMTP id mn10so1393226qvb.10 for ; Thu, 18 Aug 2022 08:15:28 -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=dFlR+kVj2uD9UOur+jUUSEp6wbEihFPG+kHsz1n5cgs=; b=CbW7kHPXN7edmSykq6ef/Te7frchoYEFOx4Z4ISFuWRJMIZwjiYZfh5cuyRGy1aiqS 4rBgS5CUWR7LxxjCBbq+2RxrqzL6x6wtw5YqVnFtWow36/suiJBHRMQMiR1ZRyWYXQFs GgQBag+sXfoxMzpX9l/VSmJNpi5lL8A5m95TRJHsff+ZWUoBeSWdgNh7t4qXegJL6Y7y aOftTXIuP3v23JoxWxFSawH0jVQWXHSxEEYYO5ysdpsVsob6Pr10htreR1rsQDaCE0g5 ubUM83pPA0UKyhAWEMPuxMWyS88+FEgZuGoQ0UgS4zdC2qIiYf55VA6MVc+8Gq1yOJqt WwjA== X-Gm-Message-State: ACgBeo1ig9BGggbSU/DS2Wt3wlS7x63ocd9rM/7kY8MFDIwsz7blWQUS DHtoClmu/DYjiMrrxrSTbw37D6BSeAvIZXy7cN4= X-Google-Smtp-Source: AA6agR45LNt3HffYM/MZRWZJ44gVwI2XUYzpczpCLdknwuQsfeja0ogY03f7SDZdB5w1XfGmYtV1O6tccDTWjPqsCxI= X-Received: by 2002:ad4:5c88:0:b0:476:7fc7:a24 with SMTP id o8-20020ad45c88000000b004767fc70a24mr3180979qvh.28.1660835728165; Thu, 18 Aug 2022 08:15:28 -0700 (PDT) MIME-Version: 1.0 References: <32216291-fd1f-4579-87de-d24cb7190894@suse.com> <995353db-27f3-ea60-8e69-32bcc44dfd49@suse.com> In-Reply-To: <995353db-27f3-ea60-8e69-32bcc44dfd49@suse.com> From: "H.J. Lu" Date: Thu, 18 Aug 2022 08:14:52 -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.6 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: Thu, 18 Aug 2022 15:15:30 -0000 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. > 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? > 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. > > Jan -- H.J.