From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) by sourceware.org (Postfix) with ESMTPS id DCEA63858D28 for ; Mon, 11 Dec 2023 16:50:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DCEA63858D28 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 DCEA63858D28 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::436 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702313436; cv=none; b=q9PMSXjoLsu4l+YSSPQPaCPZy8D/5U1SxLEdmzMcBwLYOIkaE3L7M2IDraBPpwGHqOoTXCb0rRXtd0Fu0tWO1FPbge78N3VLKmUVFY0n5fMZDBOS/W7xJrv9/uSEmsXWTqPhCQjhW+OIlk2ngHHwmOT781JYzGpGw4OAS2tJ4Kg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702313436; c=relaxed/simple; bh=KbjVm6eMsPzh0TtfgZ/9yjKxXtKRlWss9N5BILSR1Do=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=XRgrSQTP7+dOP1UfM/lL2ywF5YkqR+bnC5qbErF7jlm+bb1Uu/bwNm+93fqA8zdnWe+kZQMVkTykh509DQ7mAQKmZC48TzTKRAMRwDp1f69t7vSINknNlF9DtKAoAK+HUB51mlV+2ialYxyebGiyHN96xLpbZSQDQ9yDTe6CH/s= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wr1-x436.google.com with SMTP id ffacd0b85a97d-333630e9e43so4848787f8f.2 for ; Mon, 11 Dec 2023 08:50:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1702313431; x=1702918231; 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=7BrYvj2fholPKHJTzab5MvnZSE2PCE7MxpyulCgXsoo=; b=ehlR53EA8gIle76jqbPjf44QnBjsPx32Vq7MUFQnYGvf08dM+YS/j4tJ/TWfxIz2ll rBljRF+YnWxe6VeDDBr+UsHHzKvT7VBukeARHmNwLkGGEyGgNM7ugZdS13ZJrfRVwMAV EV2HxzugG+ow31l0ARUwAn/qaH3EQ981zbLQCnZm5BFF0smDEhyqOKSJcyYJ9JquqhKI 9ZlqrKxFTA5tlIT5PPTTVHwvIXLkrnQHyjdQpqbkWOK9YN/YpLSKjPMvjMEqDTbYpCN9 xwRfgGkPb4vz8KfKgHjfBou/lB1zhAOpnIQzaG3cTdgHoRDR9MXyfRY8IKx8S7/hrc+c WrBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702313431; x=1702918231; 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=7BrYvj2fholPKHJTzab5MvnZSE2PCE7MxpyulCgXsoo=; b=gsjQTXDQpIs0qCmtNXcXGF77tB80T4YxyCgFpO318NREWAuTvkxJ76FmTJGJ1twi1w sqTStLxn8I9aLAfBicKRfruAoiZjYoRneLuIY9fCoIEXNUD3vAeKGIn0OHDJKgehiFUk IpxMGQn6L/iHOcPOn0Zf8wjeHwSGei0tod1KLTdwTb3hwwiCNoDLQXpZJjWdZpqptD1/ sKVM9m90TnlEEv2kRdOF4j9ktrQp9DvzxjWT6GFdDy+OVXe7ZxTs1h9hJPYK8/CAT9pk 5nREMx+yg2hQ5utSgUhytpQCAEXMKNU/MI45ZXkmPUxBRW9NpM05ycOuuSAbiMPC7k2t UgVw== X-Gm-Message-State: AOJu0Yz9rJfqllqaZOPFxCxsk3jWJal9ge8CVxssd8S3Lzcp8315zZL0 rV0jVOqYmSIfsTgHtq0oY08e X-Google-Smtp-Source: AGHT+IEjQTeQfUQ0beXE3TyqAKxzvezQgP3nrrZPYI54p7A3HFHmUlRKR3C9oLouXEQPLONxmQ/mRA== X-Received: by 2002:adf:ef87:0:b0:333:2edd:84f1 with SMTP id d7-20020adfef87000000b003332edd84f1mr1769531wro.27.1702313431477; Mon, 11 Dec 2023 08:50:31 -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 l6-20020a5d4bc6000000b00333381c6e12sm8989975wrt.40.2023.12.11.08.50.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Dec 2023 08:50:31 -0800 (PST) Message-ID: <3ff16131-d959-4ac0-85e2-7f3a7a1b28b3@suse.com> Date: Mon, 11 Dec 2023 17:50:12 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 6/9] Support APX NDD Content-Language: en-US To: "Cui, Lili" Cc: "Lu, Hongjiu" , "Kong, Lingling" , "binutils@sourceware.org" References: <20231124070213.3886483-1-lili.cui@intel.com> <20231124070213.3886483-6-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: 7bit X-Spam-Status: No, score=-3026.4 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 11.12.2023 14:36, Cui, Lili wrote: >> On 24.11.2023 08:02, Cui, Lili wrote: >>> --- a/opcodes/i386-opc.tbl >>> +++ b/opcodes/i386-opc.tbl >>> @@ -139,9 +139,13 @@ >>> #define Vsz256 Vsz=VSZ256 >>> #define Vsz512 Vsz=VSZ512 >>> >>> +#define DstVVVV VexVVVV=VexVVVV_DST >>> + >>> // The EVEX purpose of StaticRounding appears only together with SAE. >>> Re-use // the bit to mark commutative VEX encodings where swapping >>> the source // operands may allow to switch from 3-byte to 2-byte VEX >> encoding. >>> +// And re-use the bit to mark some NDD insns that swapping the source >>> +operands // may allow to switch from EVEX encoding to REX2 encoding. >>> #define C StaticRounding >>> >>> #define FP 387|287|8087 >>> @@ -288,26 +292,40 @@ std, 0xfd, 0, NoSuf, {} sti, 0xfb, 0, NoSuf, {} >>> >>> // Arithmetic. >>> +add, 0x0, APX_F, >>> >> +D|C|W|CheckOperandSize|Modrm|No_sSuf|DstVVVV|EVex128|EVexMap4|N >> F, { >>> +Reg8|Reg16|Reg32|Reg64, >>> >> +Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseInde >> x, >>> +Reg8|Reg16|Reg32|Reg64 } >> >> There is _still_ Byte|Word|Dword|Qword in here (and below), when I think I >> pointed out more than once before that in new templates such redundancy >> wants omitting. >> >> Since this isn't the first instance of earlier review comments not taken care of, >> may I please ask that you make reasonably sure that new versions aren't sent >> out like this? >> > > This part could indeed be omitted, but I really don't remember you mentioning it on the APX patches. Already in e.g. https://sourceware.org/pipermail/binutils/2023-November/130422.html I pointed out that such earlier comments in e.g. https://sourceware.org/pipermail/binutils/2023-September/129590.html were not addressed. > There are still a lot of redundant Byte|Word|Dword|Qword in the opcode table, APX just added some flags on top of the old ones. Do you mind if I create a patch first to remove the redundant parts of master? I don't mind you cleaning up first. It's just that normally I wouldn't do so in a separate patch (one of the reasons being that such non-functional changes get in the way of using "git blame" or alike when trying to find the most recent real change to a line), unless it was only a handful of instances left. Instead I typically do such tidying as lines are touched anyway. Thing here simply is that new templates shouldn't have such anomalies anymore. >>> add, 0x0, 0, D|W|CheckOperandSize|Modrm|No_sSuf|HLEPrefixLock, { >>> Reg8|Reg16|Reg32|Reg64, >>> >> Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseIndex >> } >>> +add, 0x83/0, APX_F, >>> >> +Modrm|CheckOperandSize|No_bSuf|No_sSuf|DstVVVV|EVex128|EVexMap4| >> NF, { >>> +Imm8S, Reg16|Reg32|Reg64|Word|Dword|Qword|Unspecified|BaseIndex, >>> +Reg16|Reg32|Reg64 } >>> add, 0x83/0, 0, Modrm|No_bSuf|No_sSuf|HLEPrefixLock, { Imm8S, >>> Reg16|Reg32|Reg64|Word|Dword|Qword|Unspecified|BaseIndex } add, >> 0x4, >>> 0, W|No_sSuf, { Imm8|Imm16|Imm32|Imm32S, >> Acc|Byte|Word|Dword|Qword } >>> +add, 0x80/0, APX_F, >>> +W|Modrm|CheckOperandSize|No_sSuf|DstVVVV|EVex128|EVexMap4|NF, { >>> +Imm8|Imm16|Imm32|Imm32S, >>> >> +Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseInde >> x, >>> +Reg8|Reg16|Reg32|Reg64} >>> add, 0x80/0, 0, W|Modrm|No_sSuf|HLEPrefixLock, { >>> Imm8|Imm16|Imm32|Imm32S, >>> >> Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseIndex >> } >>> >>> inc, 0x40, No64, No_bSuf|No_sSuf|No_qSuf, { Reg16|Reg32 } >>> +inc, 0xfe/0, APX_F, >>> +W|Modrm|No_sSuf|CheckOperandSize|DstVVVV|EVex128|EVexMap4|NF, >>> >> +{Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseInde >> x, >>> +Reg8|Reg16|Reg32|Reg64} >>> inc, 0xfe/0, 0, W|Modrm|No_sSuf|HLEPrefixLock, { >>> >> Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseIndex >> } >>> >>> +sub, 0x28, APX_F, >>> >> +D|W|CheckOperandSize|Modrm|No_sSuf|DstVVVV|EVex128|EVexMap4|Opti >> mize| >>> +NF, { Reg8|Reg16|Reg32|Reg64, >>> >> +Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseInde >> x, >>> +Reg8|Reg16|Reg32|Reg64, } >> >> Here and elsewhere, what's Optimize for? It not being there on other >> templates, it can't be for the EVEX->REX2 optimization? If there are further >> optimization plans, that's (again) something to mention in the description. Yet >> better would be if such attributes were added only when respective >> optimizations are actually introduced. Unlike e.g. NF, which would mean >> another bulk update if not added right away, new optimizations typically affect >> only a few templates at a time. >> > > Optimize is not new. > > sub, 0x28, APX_F, D|W|CheckOperandSize|Modrm|No_sSuf|DstVVVV|EVex128|EVexMap4|Optimize|NF, { Reg8|Reg16|Reg32|Reg64, Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseIndex, Reg8|Reg16|Reg32|Reg64, } > sub, 0x28, 0, D|W|CheckOperandSize|Modrm|No_sSuf|HLEPrefixLock|Optimize, { Reg8|Reg16|Reg32|Reg64, Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseIndex } Optimize is legitimately there for the legacy template. If the new template also wants it, there needs to be some reason. Otherwise it is part of the tranformation to APX/EVEX to drop it. >>> sub, 0x28, 0, >>> D|W|CheckOperandSize|Modrm|No_sSuf|HLEPrefixLock|Optimize, { >>> Reg8|Reg16|Reg32|Reg64, >>> >> Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseIndex >> } >>> +sub, 0x83/5, APX_F, >>> +Modrm|No_bSuf|No_sSuf|DstVVVV|EVex128|EVexMap4|NF, { Imm8S, >>> +Reg16|Reg32|Reg64|Word|Dword|Qword|Unspecified|BaseIndex, >>> +Reg16|Reg32|Reg64 } >>> sub, 0x83/5, 0, Modrm|No_bSuf|No_sSuf|HLEPrefixLock, { Imm8S, >>> Reg16|Reg32|Reg64|Word|Dword|Qword|Unspecified|BaseIndex } sub, >> 0x2c, >>> 0, W|No_sSuf, { Imm8|Imm16|Imm32|Imm32S, >> Acc|Byte|Word|Dword|Qword } >>> +sub, 0x80/5, APX_F, >>> +W|Modrm|CheckOperandSize|No_sSuf|DstVVVV|EVex128|EVexMap4|NF, { >>> +Imm8|Imm16|Imm32|Imm32S, >>> >> +Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseInde >> x, >>> +Reg8|Reg16|Reg32|Reg64 } >>> sub, 0x80/5, 0, W|Modrm|No_sSuf|HLEPrefixLock, { >>> Imm8|Imm16|Imm32|Imm32S, >>> >> Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseIndex >> } >> >> There are still only 3 new templates here (and also above for add, plus for >> other similar insns), when ... >> >>> dec, 0x48, No64, No_bSuf|No_sSuf|No_qSuf, { Reg16|Reg32 } >>> +dec, 0xfe/1, APX_F, >>> +W|Modrm|CheckOperandSize|No_sSuf|DstVVVV|EVex128|EVexMap4|NF, { >>> >> +Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseInde >> x, >>> +Reg8|Reg16|Reg32|Reg64 } >>> dec, 0xfe/1, 0, W|Modrm|No_sSuf|HLEPrefixLock, { >>> >> Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseIndex >> } >>> >>> +sbb, 0x18, APX_F, >>> +D|W|CheckOperandSize|Modrm|No_sSuf|DstVVVV|EVex128|EVexMap4, { >>> +Reg8|Reg16|Reg32|Reg64, >>> >> +Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseInde >> x, >>> +Reg8|Reg16|Reg32|Reg64 } >>> sbb, 0x18, 0, D|W|CheckOperandSize|Modrm|No_sSuf|HLEPrefixLock, { >>> Reg8|Reg16|Reg32|Reg64, >>> >> Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseIndex >> } >>> +sbb, 0x18, APX_F, >>> +D|W|CheckOperandSize|Modrm|EVex128|EVexMap4|No_sSuf, { >>> +Reg8|Reg16|Reg32|Reg64, >>> >> +Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseInde >> x } >>> +sbb, 0x83/3, APX_F, >>> >> +Modrm|CheckOperandSize|No_bSuf|No_sSuf|DstVVVV|EVex128|EVexMap4, >> { >>> +Imm8S, Reg16|Reg32|Reg64|Word|Dword|Qword|Unspecified|BaseIndex, >>> +Reg16|Reg32|Reg64 } >>> sbb, 0x83/3, 0, Modrm|No_bSuf|No_sSuf|HLEPrefixLock, { Imm8S, >>> Reg16|Reg32|Reg64|Word|Dword|Qword|Unspecified|BaseIndex } >>> +sbb, 0x83/3, APX_F, Modrm|EVex128|EVexMap4|No_bSuf|No_sSuf, >> { Imm8S, >>> +Reg16|Reg32|Reg64|Word|Dword|Qword|Unspecified|BaseIndex } >>> sbb, 0x1c, 0, W|No_sSuf, { Imm8|Imm16|Imm32|Imm32S, >>> Acc|Byte|Word|Dword|Qword } >>> +sbb, 0x80/3, APX_F, >>> +W|Modrm|CheckOperandSize|No_sSuf|DstVVVV|EVex128|EVexMap4, { >>> +Imm8|Imm16|Imm32|Imm32S, >>> >> +Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseInde >> x, >>> +Reg8|Reg16|Reg32|Reg64 } >>> sbb, 0x80/3, 0, W|Modrm|No_sSuf|HLEPrefixLock, { >>> Imm8|Imm16|Imm32|Imm32S, >>> >> Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseIndex >> } >>> +sbb, 0x80/3, APX_F, W|Modrm|EVex128|EVexMap4|No_sSuf, { >>> +Imm8|Imm16|Imm32|Imm32S, >>> >> +Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseInde >> x } >> >> ... there are 6 new templates here. This is again an aspect I had pointed out >> before. You cannot defer the addition of the other 3 until the NF patch, as you >> want to make sure that with just this patch in place something both >> >> {evex} sbb %eax, %eax >> >> and >> >> {evex} sub %eax, %eax >> >> actually assemble, and to EVEX encodings. I can't see how that would work in >> the latter case without those further templates. >> >> The alternative is to also defer adding the 2-operand SBB templates (and any >> others you add here which don't use DstVVVV). >> > > I'm having a headache with this, some instructions like sbb don't support NF, originally they were in the 4/9 patch, but their disassemblers are in the NDD patch, and you agreed to put them in the NDD patch. Right, yet still the overall result wants to be consistent. Hence why I'm not demanding that you move these templates yet later (which is one option). Instead I've indicated that moving the others ahead would also be okay. Like with any series, you want it to be in a shape where it can be committed piecemeal. Which is even more important with a release around the corner. If we end up with just partial APX support in 2.42, that partial support should be in a shape that's predictable to users. > Now I really don't know where to move. Moving encoding, decoding, and especially test cases for instructions between patches is cumbersome and I really don't think it makes much sense. I can see your point, and I'm sorry for the hassle. Part of the problem of the moving being troublesome is (imo) that many of the patches simply were (are) doing too many things at a time anyway. >>> xor, 0x30, 0, >>> D|W|CheckOperandSize|Modrm|No_sSuf|HLEPrefixLock|Optimize, { >>> Reg8|Reg16|Reg32|Reg64, >>> >> Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseIndex >> } >>> +xor, 0x83/6, APX_F, >>> >> +Modrm|CheckOperandSize|No_bSuf|No_sSuf|DstVVVV|EVex128|EVexMap4| >> NF, { >>> +Imm8S, Reg16|Reg32|Reg64|Word|Dword|Qword|Unspecified|BaseIndex, >>> +Reg16|Reg32|Reg64 } >>> xor, 0x83/6, 0, Modrm|No_bSuf|No_sSuf|HLEPrefixLock, { Imm8S, >>> Reg16|Reg32|Reg64|Word|Dword|Qword|Unspecified|BaseIndex } xor, >> 0x34, >>> 0, W|No_sSuf, { Imm8|Imm16|Imm32|Imm32S, >> Acc|Byte|Word|Dword|Qword } >>> +xor, 0x80/6, APX_F, >>> +W|Modrm|CheckOperandSize|No_sSuf|DstVVVV|EVex128|EVexMap4|NF, { >>> +Imm8|Imm16|Imm32|Imm32S, >>> >> +Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseInde >> x, >>> +Reg8|Reg16|Reg32|Reg64 } >>> xor, 0x80/6, 0, W|Modrm|No_sSuf|HLEPrefixLock, { >>> Imm8|Imm16|Imm32|Imm32S, >>> >> Reg8|Reg16|Reg32|Reg64|Byte|Word|Dword|Qword|Unspecified|BaseIndex >> } >>> >>> // clr with 1 operand is really xor with 2 operands. >>> clr, 0x30, 0, W|Modrm|No_sSuf|RegKludge|Optimize, { >>> Reg8|Reg16|Reg32|Reg64 } >> >> Btw., for consistency this may also want accompanying with an EVEX >> counterpart. >> > > Do you mean to add an entry like this? It should belong to the previous patch. > > // clr with 1 operand is really xor with 2 operands. > clr, 0x30, 0, W|Modrm|No_sSuf|RegKludge|Optimize, { Reg8|Reg16|Reg32|Reg64 } > clr, 0x30, APX_F, W|Modrm|No_sSuf|RegKludge|EVex128|EVexMap4|Optimize, { Reg8|Reg16|Reg32|Reg64 } Yes, something like this. And possibly indeed not the patch here; the template simply happened to be in context. Where exactly it wants to go depends - see above - on where other similar templates are introduced. Note however that the corresponding XOR templates are introduced here, just above and still in context. Jan