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

[Jan Beulich]

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.

Jan