Re: [PATCH] x86: Support BHI_CTRL instruction

On 03.06.2026 10:08, Jan Beulich wrote:
> On 03.06.2026 09:47, Jiang, Haochen wrote:
>>> From: Jiang, Haochen
>>> Sent: Wednesday, June 3, 2026 10:38 AM
>>> To: 'Jan Beulich' <[email protected]>
>>>
>>>> From: Jan Beulich <[email protected]>
>>>> Sent: Tuesday, June 2, 2026 4:27 PM
>>>>
>>>> On 01.06.2026 08:24, Haochen Jiang wrote:
>>>>
>>>>> --- a/opcodes/i386-opc.tbl
>>>>> +++ b/opcodes/i386-opc.tbl
>>>>> @@ -3630,3 +3630,9 @@ vmovrs<bw>, 0xf26f, AVX10_2&MOVRS&x64,
>>>> Modrm|Masking|Map5|<bw:vexw>|Disp8ShiftVL
>>>>>  vmovrs<dq>, 0xf36f, AVX10_2&MOVRS&x64,
>>>>
>>> Modrm|Masking|Map5|<dq:vexw>|Disp8ShiftVL|CheckOperandSize|NoSuf,
>>>> { Xmmword|Ymmword|Zmmword|Unspecified|BaseIndex,
>>>> RegXMM|RegYMM|RegZMM }
>>>>>
>>>>>  // MOVRS instructions end.
>>>>> +
>>>>> +// BHI_CTRL insructions.
>>>>> +
>>>>> +ibhf, 0xf30f1ef8, BHI_CTRL, NoSuf|Size64, {}
>>>>
>>>> So Size64 is here to have REX.W emitted. The whitepaper isn't clear about
>>> APX
>>>> at all, though: Would REX2.W also have the same effect? (Whichever way it
>>> is,
>>>> this then perhaps also wants covering in the testsuite.)
>>>
>>> No, it won't. The encoding is fixed. But a testcase is welcomed here to clarify.
>>
>> But you had a good point here, the current disassembler won't "reject" rex2.w
>> (i.e., not taking this back to nop from my understanding) and take it as rex.w.
>>
>> This let me further wonder if a user input something like "{rex2} ibhf", should we
>> accept that? Let me double check that.
> 
> We should accept it if the resulting encoding does what is intended / written.
> According to Christian's reply REX2.W doesn't have the same effect, but I wonder
> if it's really sensible that way. The W bits, whether encoded in REX or REX2,
> really ought to have the same meaning as per the APX spec. Unless of course this
> is indeed meant to be another special case besides PUSHP/POPP (when imo it would
> be really nice if special cases were avoided whenever possible).

Has this been clarified in the meantime? It's somewhat sad that 2.47 shipped
without this addition, when that has been missing for quite some time.

Jan