[PATCH] x86: Support BHI_CTRL instruction

[Jiang, Haochen]

> From: Jan Beulich <jbeulich@suse.com>
> Sent: Wednesday, June 3, 2026 4:08 PM
> 
> 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
> >>>
> >>> 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).

I am confirming with arch team for these issues. This instruction seems to me
the first instruction we only borrowed W1 with no effect, other using REX.W1
at least implied operand size. This definitely needs some clarification.

Will come back to you all after I get a clear answer.

Thx,
Haochen