[PATCH] x86: Support BHI_CTRL instruction

Jiang, Haochen haochen.jiang@intel.com
Wed Jun 3 02:37:39 GMT 2026


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

> 
> In any event, I don't think we want the i386-gen.c change; instead we want
> x64&BHI_CTRL here: Aiui BHI_CTRL itself isn't 64-bit only, it's only this new
> insn which is.

I am okay with both solutions. But, yes, if we have a new inst in this ISA
(although very low probability) that supports both 32 and 64 bit, then the
current implementation will need re-do. And your point also stands.

Thus, I will change to x64&BHI_CTRL.

Thx,
Haochen


More information about the Binutils mailing list