[PATCH] x86: Support BHI_CTRL instruction

[Jan Beulich]

On 03.06.2026 09:47, Jiang, Haochen wrote:
>> From: Jiang, Haochen
>> Sent: Wednesday, June 3, 2026 10:38 AM
>> To: 'Jan Beulich' <jbeulich@suse.com>
>>
>>> From: Jan Beulich <jbeulich@suse.com>
>>> 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).

Jan