[PATCH 1/8] Support APX GPR32 with rex2 prefix
Jan Beulich
jbeulich@suse.com
Mon Nov 6 15:02:44 GMT 2023
On 02.11.2023 12:29, Cui, Lili wrote:
> @@ -1119,6 +1148,18 @@ process_i386_opcode_modifier (FILE *table, char *mod, unsigned int space,
> fprintf (stderr,
> "%s: %d: W modifier without Word/Dword/Qword operand(s)\n",
> filename, lineno);
> +
> + /* The part about judging EVEX encoding should be synchronized with
> + is_evex_encoding. */
> + if (modifiers[Vex].value
> + || ((space > SPACE_0F || has_special_handle)
> + && !modifiers[EVex].value
> + && !modifiers[Disp8MemShift].value
> + && !modifiers[Broadcast].value
> + && !modifiers[Masking].value
> + && !modifiers[SAE].value))
> + modifiers[NoEgpr].value = 1;
While this is just i386-gen (and hence being somewhat inefficient isn't the
end of the world) I still wonder whether we need all the parts of this condition:
Do we really need all the constituents of this EVEX related checks? Wouldn't it
also help is_evex_encoding() if we switched to uniformly having EVex attributes
on all EVEX templates? A presently missing EVex attribute, after all, merely is
another way of saying EVexDYN, if I'm not mistaken. (Such an adjustment, if
deemed to help, would of course want to come as a separate, prereq patch.)
Furthermore, is this correct at all for mixed VEX/EVEX templates?
> --- a/opcodes/i386-opc.tbl
> +++ b/opcodes/i386-opc.tbl
> @@ -891,7 +891,7 @@ rex.wrxb, 0x4f, x64, NoSuf|IsPrefix, {}
> <pseudopfx:ident:cpu, disp8:Disp8:0, disp16:Disp16:0, disp32:Disp32:0, +
> load:Load:0, store:Store:0, +
> vex:VEX:0, vex2:VEX:0, vex3:VEX3:0, evex:EVEX:0, +
> - rex:REX:x64, nooptimize:NoOptimize:0>
> + rex:REX:x64, rex2:REX2:x64, nooptimize:NoOptimize:0>
Seeing this I realized that there's something missing here (an APX_F dependency),
which then again would not have had an effect without the patch [1] sent earlier
today.
Jan
[1] https://sourceware.org/pipermail/binutils/2023-November/130345.html
More information about the Binutils
mailing list