x86/APX: clarification needed for where REX2 may be applied

[Cui, Lili]

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Thursday, February 6, 2025 7:24 PM
> To: Cui, Lili <lili.cui@intel.com>
> Cc: Binutils <binutils@sourceware.org>; Jiang, Haochen
> <haochen.jiang@intel.com>; H.J. Lu <hjl.tools@gmail.com>
> Subject: Re: x86/APX: clarification needed for where REX2 may be applied
> 
> On 06.02.2025 08:01, Cui, Lili wrote:
> >> -----Original Message-----
> >> From: Jan Beulich <jbeulich@suse.com>
> >> Sent: Monday, January 27, 2025 4:42 PM
> >> To: Cui, Lili <lili.cui@intel.com>
> >> Cc: Binutils <binutils@sourceware.org>; Jiang, Haochen
> >> <haochen.jiang@intel.com>; H.J. Lu <hjl.tools@gmail.com>
> >> Subject: Re: x86/APX: clarification needed for where REX2 may be
> >> applied
> >>
> >> On 26.01.2025 04:27, Cui, Lili wrote:
> >>>> -----Original Message-----
> >>>> From: Jan Beulich <jbeulich@suse.com>
> >>>> Sent: Friday, January 24, 2025 7:29 PM
> >>>>
> >>>> Hello,
> >>>>
> >>>> the spec has two relevant bullet points:
> >>>>
> >>>> – All instructions in legacy maps 0 and 1 that have explicit GPR or
> >>>>   memory operands can use the REX2 prefix to access the upper 16 GPRs
> >>>>   (namely, R16 to R31).
> >>>>
> >>>> – Certain rows of opcodes in legacy maps 0 and 1 which do not have
> >>>>   explicit GPR or memory operands are reserved under REX2 for future
> >>>>   use.
> >>>>
> >>>> Later those rows are enumerated. This row related statement is kind
> >>>> of redundant though with the earlier one, for no insn in those rows
> >>>> having any explicit GPR or memory operands (map 0 row A entries 0-3
> >>>> are slightly special, but for the purpose here I take it these have
> >>>> displacement operands, not "explicit memory" ones). Yet then, with
> >>>> this being kind of redundant, the question arises how strict the
> >>>> first statement really is (i.e. whether it implies "other insns can't").
> >>>
> >>> I think the early sentence emphasizes that we can use REX2 to access
> >>> 16
> >> GPRs, but it doesn't explicitly say that REX2 is disabled for
> >> instructions without GPR or memory, so the second sentence is needed
> >> to add this point. There may be a better way to express it, but I
> >> think there is no big problem with the current expression.
> >>>
> >>>> Right now both gas and objdump don't follow that statement (or its
> >>>> implication, to be precise), but implement the restriction purely
> >>>> based on row numbers. The more I read the first statement though,
> >>>> the more it looks to me that what we currently do is wrong.
> >>>> Therefore - can this be clarified please, both here and in a future
> revision of the spec?
> >>>
> >>> I'm curious if you found some special instructions (without GPR or
> >>> memory)
> >> that are not included in the second sentence.
> >>
> >> If REX2 may be present on insns without any explicit register/memory
> >> operands, but outside of the designated "forbidden" rows, some very
> >> funny situations arise. For example, while INS and OUTS may then be
> >> REX2-prefixed, all of the other string insns (not counting XLAT as such)
> can't be.
> >>
> >
> > Good question. The APX spec folks gave a detailed explanation. I summarize
> it briefly.
> >
> > To reserve the "REX2" encoding space for future use. We decided to only
> reserve the full rows of the opcode maps in 0/1 – and not piece-wise,
> individual opcodes; INS/OUTS and PUSH imm are not in a row that was fully
> reservable (MOVSXD, IMUL, etc.), nor “half” reservable, so that row was not
> reserved.
> 
> Thanks for confirming. We're therefore doing things correctly in this regard.
> 
> >> For context: When doing further libbfd side work for GOTPCREL
> >> relaxation, I ended up quite puzzled that PUSH <imm>, when (kind of
> >> by accident) encoded with a REX2 prefix, actually disassembled okay.
> >> If it's indeed permitted, it would actually simplify things there (even if just
> a little).
> >
> > For instructions without GPR and memory that are not disabled in the APX
> spec, maybe we can simplify them under options, I'm not sure if anyone
> would want to use rex2 for byte alignment or something?
> 
> I fear I don't understand what your asking and/or suggesting.
> 

Oh, I misunderstood what you meant earlier. I thought you wanted to optimize those redundant rex2. Just forget about it.

Lili.