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

[H.J. Lu]

On Wed, Sep 9, 2026 at 5:15 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 09.09.2026 09:32, Cui, Lili wrote:
> >> -----Original Message-----
> >> From: Jan Beulich <jbeulich@suse.com>
> >> Sent: Wednesday, September 9, 2026 2:52 PM
> >>
> >> 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.
>
> Please allow me to disagree: Extra clutter is a problem. You cannot expect
> everyone to even know what that hex number means, even if they know of the
> concept of REX2 prefixes. The REX representation, at the very least, is
> human-readable without (much) apriori knowledge.
>
> Plus, just to repeat, people may be familiar with pseudo-prefixes gas
> accepts. Which {rex2} is, but {rex2 0x..} is not.

People should understand that the REX prefix has 2 bytes.  {rex2 0xXX}
may not be the best representation.   It is a compromise, instead of
pseudos to represent all REX2 combinations.


-- 
H.J.