[PATCH] x86/APX: limit printing of REX2 payload

[Cui, Lili]

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Wednesday, September 9, 2026 2:52 PM
> To: H.J. Lu <hjl.tools@gmail.com>
> Cc: Jiang, Haochen <haochen.jiang@intel.com>; Cui, Lili <lili.cui@intel.com>;
> Binutils <binutils@sourceware.org>
> Subject: Re: [PATCH] x86/APX: limit printing of REX2 payload
> 
> On 09.09.2026 08:36, H.J. Lu wrote:
> > On Wed, Sep 9, 2026 at 1:52 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 09.09.2026 07:50, Jiang, Haochen wrote:
> >>>> From: Jan Beulich <jbeulich@suse.com>
> >>>> Sent: Tuesday, September 8, 2026 11:11 PM
> >>>>
> >>>> When set bits were properly consumed (and hence all we want is an
> >>>> indication that REX2-encoding is in use), print merely {rex2}, thus
> >>>> also better matching original input.
> >>>>
> >>>> While effectively copying parts of an existing conditional, also
> >>>> simplify the original: There's no need to apply the 3-bit mask twice.
> >>>>
> >>>> While adjusting testcases, also escape curly braces.
> >>>
> >>> Actually, when I am working on BHI_CTRL patch, I have the same
> >>> question for why we are printing {rex2 0x88}. Thus, I asked Lili for
> >>> that. Lili told me that back to the very beginning, it is H.J
> >>> requested to add those additional info to express the rex2 prefix.
> >>
> >> And we still do when there are unconsumed bits.
> >>
> >>> Maybe we need H.J's input on this.
> >>
> >> Sure, I'm not going to commit right away.
> >>
> >
> > {rex} and {rex2} are different.
> >
> > [hjl@gnu-tgl-3 tmp]$ cat x.s
> > {rex} movl %eax,%ebx
> > {rex2} movl %eax,%ebx
> > [hjl@gnu-tgl-3 tmp]$ gcc -c x.s
> > [hjl@gnu-tgl-3 tmp]$ objdump -dw x.o
> >
> > x.o:     file format elf64-x86-64
> >
> >
> > Disassembly of section .text:
> >
> > 0000000000000000 <.text>:
> >    0: 40 89 c3             rex mov %eax,%ebx
> >    3: d5 00 89 c3           {rex2 0x0} mov %eax,%ebx
> 
> What useful extra information does the 0x0 supply here? Same as in the IBHF
> example, where the 0x88 is entirely redundant. In fact printing bit 7 is
> _always_ redundant (unless the prefix was printed as a "standalone" one), as
> it necessarily participated in decode.
> 

I think both forms are reasonable, and this is mostly a matter of presentation style. The proposed form is more concise, while the current form is more explicit and consistent.

The current output makes REX2 payload differences directly visible:

  d5 84 28 e7  {rex2 0x84} movaps %xmm7,%xmm12
  d5 8c 28 e7  {rex2 0x8c} movaps %xmm7,%xmm12

With this patch, the first payload would be omitted:

  d5 84 28 e7  {rex2}      movaps %xmm7,%xmm12
  d5 8c 28 e7  {rex2 0x8c} movaps %xmm7,%xmm12

Since the current output is correct, preserves the complete REX2 payload, and already has test coverage, keeping the existing behavior seems like a reasonable choice. There does not seem to be a strong need to change it.

Thanks,
Lili
> > [hjl@gnu-tgl-3 tmp]$
> >
> > {rex} maps to 0x40.  But {rex2} maps to different 2 bytes.
> > {rex2 0x0} tells what these 2 bytes are.
> 
> Whether it's one or two bytes isn't relevant. "rex" alone also doesn't make
> things entirely unambiguous, unless you know that with any of the low 4 bits
> set it wouldn't be plain "rex". IOW the rex printing only indicates (consumed
> and unconsumed) bits which are _set_ (and only if there are unconsumed
> bits), plus the presence of a (redundant) REX prefix. rex2 printing otoh
> indicates all bits (by printing the payload byte as-is, instead of deciphering the
> bits).
> 
> >   I prefer to keep it ASIS.
> 
> Please can we avoid (a) unnecessary clutter and (b) the inconsistency.
> 
> Plus, as said in the patch description, {rex2} is what the assembler accepts. I
> recall you stressing that disassembler output would, wherever possible, better
> match what the assembler accepts as input.
> 
> Jan