From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) by sourceware.org (Postfix) with ESMTPS id A88463858C74 for ; Tue, 2 Apr 2024 09:30:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A88463858C74 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org A88463858C74 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::42d ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712050227; cv=none; b=PqjDhhR6Nis6RRE9+TgEH3iDuqF7CcLiVIkmA7mNw6qZyMGOy/EWoipXLXrHyX3uY/EwmUhNr6Txf7qX9ock5NSk7BVViKcv/9qDinLeydGGFg+FE3ubWVQxEfqCpZtlA0UBuKHwNrUTRQb7Yjx7GF0RDBvRIdSaKL8fHPUGKvE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712050227; c=relaxed/simple; bh=Jq4dgVMZtUV+2GLHabG3LErVI7LRcnR8egJdwDWar1g=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=EEIGzpYltlUVNVteRTijblv1heGDJmdcDsKF2NfPMENOSFv1sfhGhcj6Vwt8S/g+UDd2NmjFJG0LVQ7CmcowGJ21febQ9WeqrXHPxhD69eeaAbFntJyEPtKqtjuH1i9L4EdAFTgLYGzqVp+R19QDtlsaSglfwwhh/HmsrIsfXKs= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-341cf77b86dso4629265f8f.2 for ; Tue, 02 Apr 2024 02:30:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1712050222; x=1712655022; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=RysonSumC046hhfxyAN3xWNCbOo4MJFz1+FTBeAv2J0=; b=JVZhNf878ekx9r/CxGXe83pzhXbA5vp1NhmnEMXVfIqg3OqAfQsVr3WKf3sKJ+RCda HVTJtO0MlIUfgpXNFlSWlmfyisjtz5yVGaamcN47QlLuNW4vLjB7poDfQvOIE7r40cta Hutw2MzwhUopzRNsAiDwu9ZEBL/IZrUzkAebEjmGYsctZU6cdl4t2snXcM4CbAZmGkn4 wgM3k1A6c36QklnS3P1+biavZVuAQBS/Tp1NkWn49CNdjNL0cxiWTDuSvOPrD7elEOZR +SN8widtRlj/GsdBOf6p4O3IDs2YkCpiaBWbfNwTsC1Ma+v4JoXzVa7Xl8HD1PE8FOcb SyNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712050222; x=1712655022; h=content-transfer-encoding:in-reply-to:autocrypt:from:references:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=RysonSumC046hhfxyAN3xWNCbOo4MJFz1+FTBeAv2J0=; b=dePXnWbtgJNF56bi8VLQ8WqEMz54/xBCsBQCiyCQSuqHt8GlxI3GpQVqmjf994O+Hj AqmlKdFa3PM3+STmjbYQLZmSOdhYTEN0+CUnz1byc87PYMYJLUYKyI1kpq53gYW67JuP PZgDBmJz8DxCHuO2Ai3VVyLSMjjdiChL4mM8j1UiU0pvag5IrtVzjwSpmbLbO4fosWq5 lMLxG86CoYdbjK3d7c0+rozRGFvpdq+I8l9ODyLcf5A38ZsMB+NNU2q7fQpAtI7+J3t1 ijh0rnJBNirYLJLzssSecV3MNt6W3OYDJmGjquAbWn80qbX7pX0ri3lZUIO3LvB51nzv 9jFA== X-Forwarded-Encrypted: i=1; AJvYcCXfJj89t1eeVxIgSRp7Z9r1wGnj6Yg5Mf9HK+owQXcjYqU6DHPDOZM4k9xopItZa7t4OJ2iNSdH8pMe/PK6LeVpCF603yRA+Q== X-Gm-Message-State: AOJu0YywvlR4LV86u8tvMPsDIcYwLsSuhATCuCd5ZsOE1eXWuy72o89q fdsd/ht1tqUQOgkol34tkCPxN4A05cLtvNRoDcSmFpnGrc8pVlxNvDXyfkJMyw== X-Google-Smtp-Source: AGHT+IF1ku+YEm2S+A7oheFjS7998MXPxelHntUnb/XYLOSxuRrcu3MYuT19yl8qtypCIxtbEEtRqg== X-Received: by 2002:a5d:530c:0:b0:341:d33e:da1b with SMTP id e12-20020a5d530c000000b00341d33eda1bmr1132630wrv.31.1712050222336; Tue, 02 Apr 2024 02:30:22 -0700 (PDT) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id dv10-20020a0560000d8a00b00341ce1b64f0sm13665938wrb.17.2024.04.02.02.30.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 02 Apr 2024 02:30:22 -0700 (PDT) Message-ID: Date: Tue, 2 Apr 2024 11:30:26 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH V2] Support {evex} pseudo prefix for decode evex promoted insns without egpr32. Content-Language: en-US To: "Cui, Lili" Cc: "hjl.tools@gmail.com" , "binutils@sourceware.org" References: <20240322094932.795331-1-lili.cui@intel.com> From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3024.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_ASCII_DIVIDERS,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no 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 02.04.2024 10:59, Cui, Lili wrote: >>> --- a/gas/testsuite/gas/i386/x86-64-apx-evex-promoted-bad.d >>> +++ b/gas/testsuite/gas/i386/x86-64-apx-evex-promoted-bad.d >>> @@ -30,16 +30,16 @@ Disassembly of section .text: >>> [ ]*[a-f0-9]+:[ ]+0c 18[ ]+or.* >>> [ ]*[a-f0-9]+:[ ]+62 f2 fc 18 f5[ ]+\(bad\) >>> [ ]*[a-f0-9]+:[ ]+0c 18[ ]+or.* >>> -[ ]*[a-f0-9]+:[ ]+62 f4 e4[ ]+\(bad\) >>> +[ ]*[a-f0-9]+:[ ]+62 f4 e4[ ]+\{evex\} \(bad\) >>> [ ]*[a-f0-9]+:[ ]+08 ff[ ]+.* >>> [ ]*[a-f0-9]+:[ ]+04 08[ ]+.* >>> -[ ]*[a-f0-9]+:[ ]+62 f4 3c[ ]+\(bad\) >>> +[ ]*[a-f0-9]+:[ ]+62 f4 3c[ ]+\{evex\} \(bad\) >> >> Why is this? What's the criteria for {evex} to appear ahead of (bad)? And if so >> for EVEX, shouldn't VEX gain {vex} in such cases, too? (Which is really the >> opposite I mean to indicate: No such prefixes should ever appear here. If >> anything we should present unrecognized VEX/EVEX encodings in a sufficiently >> generic way, including all of their - similarly generalized - >> operands.) > > Our rules for adding {evex} to map4 are: > 1. No NDD( means ins->vex.nd is 0). > 2. No Egprs( use ins->rex2, excluding X4). > 3. Other macros are not added {evex}/{nf}. > > For {evex} inc %rax %rbx, we set ins->vex.nd = 0, meaning it only has two operands, I think it is right to add {evex} for it. > ----------------------------------------------------------------------------------- > #{evex} inc %rax %rbx EVEX.vvvv != 1111 && EVEX.ND = 0. > .byte 0x62, 0xf4, 0xe4, 0x08, 0xff, 0x04, 0x08 > ----------------------------------------------------------------------------------- > > For pop2 %rax,%r8, it only has EVEX format, it's special because its ins->vex.nd != 0,so the normal process will not add {evex} to it, but we give it an illegal value, let ins->vex.nd = 0, so it added {evex} by mistake. This mistake is caused by illegal values. I don’t have a reasonable fix, so I prefer not to change it. > ------------------------------------------------------------------------------------ > # pop2 %rax, %r8 set EVEX.ND=0. > .byte 0x62, 0xf4, 0x3c, 0x08, 0x8f, 0xc0 > .byte 0xff, 0xff, 0xff > ------------------------------------------------------------------------------------- The POP2 aspect isn't really relevant here. Imo (bad) should never be prefixed by (pseudo) prefixes. If, however, it is to be, then such prefixing needs doing consistently. Which I'm afraid is going to be quite a bit more work than simply zapping (or avoiding) {evex} when (bad) is printed. >>> @@ -10398,6 +10402,7 @@ putop (instr_info *ins, const char *in_template, >> int sizeflag) >>> int cond = 1; >>> unsigned int l = 0, len = 0; >>> char last[4]; >>> + bool b_done = false; >> >> Mind me asking what "b" in this identifier is intended to stand for? >> > > I just want to show that it is a bool type. Maybe it would be better to change it to b_added_evex_prefix? Do you have any suggestions? I don't think we use such b_ prefixes elsewhere. "evex_printed" or some such would seem sufficient. >>> @@ -10588,7 +10604,11 @@ putop (instr_info *ins, const char >> *in_template, int sizeflag) >>> oappend (ins, "{nf} "); >>> /* This bit needs to be cleared after it is consumed. */ >>> ins->vex.nf = false; >>> + b_done = true; >>> } >>> + else if (ins->evex_type == evex_from_vex && !(ins->rex2 & 7) >>> + && ins->vex.v) >>> + oappend (ins, "{evex} "); >> >> Why would b_done not need setting here as well? >> > > We only use b_done under "ins->evex_type == evex_from_legacy". Original version, we also handle "evex_from_legacy" here, now it is merged directly into "default:". Then leaving a trap for later? Let's keep internal state properly updated: If {evex} is printed, reflect that in local variable state, too. Jan