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

[Cui, Lili]

> -----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.

> 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?

Thanks,
Lili.