[PATCH] x86: Support BHI_CTRL instruction

[Jiang, Haochen]

> 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.

Thx,
Haochen