From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) by sourceware.org (Postfix) with ESMTPS id D19063858D38 for ; Tue, 8 Nov 2022 01:22:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D19063858D38 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-ot1-x32d.google.com with SMTP id 46-20020a9d0631000000b00666823da25fso7612431otn.0 for ; Mon, 07 Nov 2022 17:22:23 -0800 (PST) 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:message-id:reply-to; bh=OV7CGfkX++oiJKgZx2Fk2cayUPCQxh2eM7WJyPH3mlA=; b=kBCMaceGdCgaI529Q6d6f7PN6mYwzdCp5MqpBd1QbfBLy9I3O4LXWUV88Q+6jhxNcv rmvwPsKvhaQmt0qfH6W6jEmDmisaJnGzLA8NVBQ3ovtCCiEJu3Ah971QGmy9SRtFUYtk OMWKmTbjxDAqWMPbSHR95FrqBTUo6NHhKXiqZnolsrjakKVWZ93GC1cYlkdRz11BF751 b1IP+PyTaPdwXdvKtLq3uS4uMIX0Td2sKBSLCb1xIOKWaDxIMkVw1VgZS0+tSqMzNOIC Z5loO29E8uOnYCV2RyDx3+M+wLzud8z9/Xj6DiWfuRSoiHOwOXz5+/6MdTDskEuIcdQp l2EQ== 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:message-id :reply-to; bh=OV7CGfkX++oiJKgZx2Fk2cayUPCQxh2eM7WJyPH3mlA=; b=r/p3ogfgbYT/KJtidvsdVVMG2zWX8zx2AaF/jHVxXctvxDyNan5cv/z/7X2i8W9t4M TnAHiy7n7W4QbNRYa25C7GFZKx8lKfgnhBGak6uMaCdBL1/RaVyfBdii3w/pDX3ey+Kd PHTxUERZo9YhbdrFgZnP6CQpRFoicQ+fzibYkxHfRmZrlJRDKOvufhaoZpPRL4qd/W74 +IPzi/b2oVMiWZY794anX66Z8zpYBoBqHQxmSK/rxNpdJILCsyuToZKkYNYPld11sYx3 3md0CUkunQkuioaNKqAGl41sCidJ9KL1v0dwdVuSIPoKHKzmqKb/Ooqke0alL7BIQzBK ju8w== X-Gm-Message-State: ACrzQf0k0vBT32/GXFPQwoagE8XuswIPM/SyZCaW+wm+yZe/HuQURuFO KIbCGZMv6VrBBsfBxHuYWE8hqyl/C3szaCAvVHY= X-Google-Smtp-Source: AMsMyM7ag85OM9UGxm15JOrUE/6MsAxMhoCPda0RRmu4EviIdYwB7GGUinuayx5+bKSwgw/5wmFN3boyzlcAdRf+zbA= X-Received: by 2002:a9d:5e04:0:b0:661:b01c:9817 with SMTP id d4-20020a9d5e04000000b00661b01c9817mr25886932oti.52.1667870543009; Mon, 07 Nov 2022 17:22:23 -0800 (PST) MIME-Version: 1.0 References: <6d71dc80-91c8-7bc8-c57f-4f771ca59fab@suse.com> <07ef67fd-752c-ad1f-b8cb-4eaec1f420fc@suse.com> In-Reply-To: From: "H.J. Lu" Date: Mon, 7 Nov 2022 17:21:46 -0800 Message-ID: Subject: Re: [PATCH v6 2/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.5 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 Mon, Nov 7, 2022 at 2:23 AM Jan Beulich wrote: > > On 05.11.2022 00:54, H.J. Lu wrote: > > On Fri, Nov 4, 2022 at 3:51 AM Jan Beulich wrote: > >> > >> Having templates with a suffix explicitly present has always been > >> quirky. Introduce a 2nd matching pass in case the 1st one couldn't find > >> a suitable template _and_ didn't itself already need to trim off a > >> suffix to find a match at all. This requires error reporting adjustments > >> (albeit luckily fewer than I was afraid might be necessary), as errors > >> previously reported during matching now need deferring until after the > >> 2nd pass (because, obviously, we must not emit any error if the 2nd pass > >> succeeds). While also related to PR gas/29524, it was requested that > >> move-with-sign-extend be left as broken as it always was. > >> > >> PR gas/29525 > >> Note that with the dropped CMPSD and MOVSD Intel Syntax string insn > >> templates taking operands, mixed IsString/non-IsString template groups > >> (with memory operands) cannot occur anymore. With that > >> maybe_adjust_templates() becomes unnecessary (and is hence being > >> removed). > >> > >> PR gas/29526 > >> Note further that while the additions to the intel16 testcase aren't > >> really proper Intel syntax, we've been permitting all of those except > >> for the MOVD variant. The test therefore is to avoid re-introducing such > >> an inconsistency. > >> --- > >> To limit code churn I'm using "goto" for the retry loop, but I'd be > >> happy to make this a proper loop either right here or in a follow-on > >> change doing just the necessary re-indentation. > >> > >> The "too many memory references" errors which are being deleted weren't > >> fully consistent anyway - even the majority of IsString insns accepts > >> only a single memory operand. If we wanted to retain that, it would need > >> re-introducing in md_assemble(), latching the error into i.error just > >> like match_template() does. > >> > >> As an unrelated observation: Why is "MOVQ $imm64, %reg64" being > >> optimized but "MOVABS $imm64, %reg64" is not? > >> --- > >> v6: Re-base over dropping of Pass2 attribute. > >> v5: Split off move-with-sign-extend changes. > >> v4: Retain support for operand-less MOVSD and CMPSD. > >> v3: Limit xstrdup() to just the templates where a 2nd pass actually > >> makes sense (new Pass2 attribute). > > > > I don't think we should add a second pass. > > So you've asked me to re-work the series several times just to _now_ > say "no" altogether? What's your alternative proposal to address the > various shortcomings that this series is addressing? (Yes, patches 4 > and 5 can, with some effort, probably be re-based ahead, but those > are only minor improvements found while doing the main piece of work > here, and they aren't strictly related to the main goal of the series.) The more I looked, the more I didn't think we needed the second pass. The issues you raised are minor issues. We shouldn't add the second pass because of them. > Plus I now really feel urged to point out that you're blocking further > work I have pending, which I keep re-basing over all the adjustments I > was making to address your comments (plus of course the new ISA > extension patches which have gone in recently, all of which also > collide with work I'm doing). This re-basing is non-trivial and hence > is consuming a considerable amount of time as well. > > Jan -- H.J.