[PATCH] x86: Correct VexSIB128 to VecSIB128

[Jan Beulich]

On 26.06.2020 18:26, H.J. Lu wrote:
> On Fri, Jun 26, 2020 at 9:17 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 26.06.2020 17:23, H.J. Lu via Binutils wrote:
>>> --- a/opcodes/i386-opc.tbl
>>> +++ b/opcodes/i386-opc.tbl
>>> @@ -84,6 +84,9 @@
>>>  #define Vex128 Vex=VEX128
>>>  #define Vex256 Vex=VEX256
>>>  #define VexLIG Vex=VEXScalar
>>> +#define VexSIB128 SIB=VECSIB128
>>> +#define VecSIB256 SIB=VECSIB256
>>> +#define VecSIB512 SIB=VECSIB512
>>
>> I first thought the typo would be only in the Changelog entry, but
>> here the first one has an x too where the others have a c. Would
>> you mind correcting this, and perhaps also adding a blank line
>> ahead of this new block of #define-s?
> 
> Fixed.
> 
> BTW, this commit:
> 
> commit c423d21a43727fb4d27c10d43e6bbedced0f55d5
> Author: Jan Beulich <jbeulich@suse.com>
> Date:   Thu Jun 25 09:30:09 2020 +0200
> 
>     x86: move ImmExt processing
> 
>     With abuses of ImmExt gone, all templates using it have operands. Move
>     its main invocation into process_operands(), matching its secondary one
>     for the SSE2AVX case.
> 
> makes this AMX entry invalid:
> 
> tilerelease, 0, 0x49, 0xc0, 1, CpuAMX_TILE|Cpu64,
> Vex|VexOpcode=1|No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf|ImmExt,
> { 0 }
> 
> Any suggestions how to address this?

Well - it introduces another abuse of ImmExt, which should be
eliminated the same way as has been done for other similar
abuses: The opcode should by 2 bytes long and have a value of
0x49c0.

Jan