[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