From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) by sourceware.org (Postfix) with ESMTPS id 4279D3858C5E for ; Fri, 22 Dec 2023 14:20:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4279D3858C5E 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 4279D3858C5E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::32f ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703254802; cv=none; b=Lb0fO85JKo2p9MkqgO8uEsbg2E3a8ZFWMJU09pVrIltbVwbe0cuTvybbLFuzXA5aX9RuxLe1UJoMhRzDpq30v+6mjkl0eM5OEnDfnkulJ1+T6rCx7z3ztFLDUC6AMSv0qFe8zBwlEuCyOV8/FwJys025CXlayk3NAgMupKhdFrk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703254802; c=relaxed/simple; bh=YLJdoQmg6jJw6UiR28ilYHwCnltU5Vv0wQYsxOGHeok=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=I5F2Jw0N6GJvyR+ExezII1dj+pX2kyMKtWH+eZGwczDYv/t1kPWT3blm+kWu971KQ/LF2xu98L1BotaSpV0nKhdkNvXiPCA2fwmEcOzjVDYBByRmQziGCXSC5UKd4KtmK+m9xfKidXWZTCS+0PIuorYw9AGLhbS9c9i1jpQwRYU= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-40d4966314cso3827755e9.2 for ; Fri, 22 Dec 2023 06:20:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1703254799; x=1703859599; 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=nEovnZDpJ/UsmWm4VLUus4S6lK+5nBEz5jBjKF0/Kms=; b=AvOeE2EkM31c5go8sVMWP83VSyU7VxJEjMOKkgpp1+/El8fyBURO3WEdY1/DShSdqm NIPjKiXA2uiK67TVbcEmbC2jb47xZWsO8icHr4U6z3/Voww2f3+PCMtcPnb0ZKEynb4H GZzCDVYYx4sorYQR34q46eh+tyUaEQzAmjrVDpJZQuqRZOHxBdLhIvoGkIrYpd4Tlyn0 Q60ljx7CcOoz3iN4QX/93BbmgvUDiDffkPEw/8b8WGXa//vHpHb+rDREZAHK2lgvKOjU bktSRwtLT6g564Naf2XUD4mDKSv1OQk6XmD6wy/1SpcmG2YKX0JrCkG2n8vfGYW/72vr lkjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703254799; x=1703859599; 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=nEovnZDpJ/UsmWm4VLUus4S6lK+5nBEz5jBjKF0/Kms=; b=WT9kRgBOFdPYbBGeibUbvTKE/StRXIOfmX5M09AsbxvYC032QyyN6PzZLDiI2HVnDX Ns30sYMvjTy6YjxIXLtF931NubJBq8Wq3dSdIMIF5hIFCWZ7pr5oS93Z87coTk2h5djr dfurFrvF7YvGP5l5yZbcNM9NeSJH7bdxYfKMKzkHckDQDIUOfOo+XTCf+UMBq7YDN4TX gHF6JZRRliAl1mWmijSDHMFPv1iCPo5JKRjFs6u3LjzZ5IqO7zshKNBASMAKx07V7yI8 3IbrL/zrQVEllqK+Z2RClEJNkXBCitxRj2YrLS/rzW77qJeTcGgx5Gheyf7c4OrMUQ2z J8WQ== X-Gm-Message-State: AOJu0YzGUNLVKeawmur1R8GCLF/TXTs/213d0UUEmijsDNN/AAJ+oAhZ vFbkjVH2ieqK3Jm5BdfTgYr57dKV8JXU X-Google-Smtp-Source: AGHT+IEcZ3hDJrq6+jBs9uYQe8knrFatmUxIuI89/TEvCYyH1V+j68Imwfi5EY+TH+R6kcp9o9tnOQ== X-Received: by 2002:a05:600c:3d98:b0:40c:1da7:a5fe with SMTP id bi24-20020a05600c3d9800b0040c1da7a5femr568351wmb.25.1703254798915; Fri, 22 Dec 2023 06:19:58 -0800 (PST) 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 d13-20020adfe84d000000b003366d79edbfsm4395767wrn.67.2023.12.22.06.19.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 22 Dec 2023 06:19:58 -0800 (PST) Message-ID: <4c64e863-22a3-43e4-a566-e05c7fb909bd@suse.com> Date: Fri, 22 Dec 2023 15:19:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 3/9] Support APX GPR32 with extend evex prefix Content-Language: en-US To: "Cui, Lili" Cc: hongjiu.lu@intel.com, binutils@sourceware.org References: <20231219121218.974012-1-lili.cui@intel.com> <20231219121218.974012-4-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: <20231219121218.974012-4-lili.cui@intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3026.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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 19.12.2023 13:12, Cui, Lili wrote: > --- a/opcodes/i386-dis-evex-prefix.h > +++ b/opcodes/i386-dis-evex-prefix.h > @@ -285,6 +285,14 @@ > { "%XEvfmsub213s%XW", { XMScalar, VexScalar, EXdq, EXxEVexR }, 0 }, > { "v4fnmadds%XS", { XMScalar, VexScalar, Mxmm }, 0 }, > }, > + /* PREFIX_EVEX_0F38F2_L_0 */ > + { > + { "andnS", { Gdq, VexGdq, Edq }, 0 }, > + }, So not being able to re-use the VEX entry for this and ... > --- a/opcodes/i386-dis-evex-reg.h > +++ b/opcodes/i386-dis-evex-reg.h > @@ -49,3 +49,10 @@ > { "vscatterpf0qp%XW", { MVexVSIBQWpX }, PREFIX_DATA }, > { "vscatterpf1qp%XW", { MVexVSIBQWpX }, PREFIX_DATA }, > }, > + /* REG_EVEX_0F38F3_L_0_P_0 */ > + { > + { Bad_Opcode }, > + { "blsrS", { VexGdq, Edq }, 0 }, > + { "blsmskS", { VexGdq, Edq }, 0 }, > + { "blsiS", { VexGdq, Edq }, 0 }, > + }, ... this was due to the VEX entries having PREFIX_OPCODE, which would be getting in the way? This is the sort of thing that would be useful to have in the description, to avoid raising the same question again that (I think) was raised before. Yet then - why do you strip PREFIX_OPCODE from the VEX entries? If you do that (as iirc I did suggest), there's no need for having separate EVEX ones (the suggestion, after all, was to be able to re-use the VEX entries). That re-work of existing VEX encodings could, btw, also have been split out quite easily. That way this huge patch would have further shrunk a little. > --- /dev/null > +++ b/opcodes/i386-dis-evex-x86-64.h > @@ -0,0 +1,50 @@ > + /* X86_64_EVEX_0F90 */ > + { > + { Bad_Opcode }, > + { VEX_W_TABLE (VEX_W_0F90_L_0) }, > + }, > + /* X86_64_EVEX_0F91 */ > + { > + { Bad_Opcode }, > + { VEX_W_TABLE (VEX_W_0F91_L_0) }, > + }, > + /* X86_64_EVEX_0F92 */ > + { > + { Bad_Opcode }, > + { VEX_W_TABLE (VEX_W_0F92_L_0) }, > + }, > + /* X86_64_EVEX_0F93 */ > + { > + { Bad_Opcode }, > + { VEX_W_TABLE (VEX_W_0F93_L_0) }, > + }, > + /* X86_64_EVEX_0F38F2 */ > + { > + { Bad_Opcode }, > + { PREFIX_TABLE (PREFIX_VEX_0F38F2_L_0) }, > + }, > + /* X86_64_EVEX_0F38F3 */ > + { > + { Bad_Opcode }, > + { PREFIX_TABLE (PREFIX_VEX_0F38F3_L_0) }, > + }, > + /* X86_64_EVEX_0F38F5 */ > + { > + { Bad_Opcode }, > + { PREFIX_TABLE (PREFIX_VEX_0F38F5_L_0) }, > + }, > + /* X86_64_EVEX_0F38F6 */ > + { > + { Bad_Opcode }, > + { PREFIX_TABLE(PREFIX_VEX_0F38F6_L_0) }, > + }, > + /* X86_64_EVEX_0F38F7 */ > + { > + { Bad_Opcode }, > + { PREFIX_TABLE(PREFIX_VEX_0F38F7_L_0) }, > + }, > + /* X86_64_EVEX_0F3AF0 */ > + { > + { Bad_Opcode }, > + { PREFIX_TABLE (PREFIX_VEX_0F3AF0_L_0) }, > + }, Am I misremembering that we had agreed that this new file isn't necessary, by having USE_X86_64_EVEX_FROM_VEX_TABLE handle the non-64-bit case? At least I couldn't find a mail from you saying this isn't possible (and why). Jan