[PATCH 2/8] Support APX GPR32 with extend evex prefix

[Jan Beulich]

On 18.10.2023 09:52, Cui, Lili wrote:
> 
> 
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Wednesday, October 18, 2023 2:47 PM
>> To: Cui, Lili <lili.cui@intel.com>
>> Cc: Lu, Hongjiu <hongjiu.lu@intel.com>; binutils@sourceware.org
>> Subject: Re: [PATCH 2/8] Support APX GPR32 with extend evex prefix
>>
>> On 18.10.2023 08:31, Cui, Lili wrote:
>>>>>> Similary I don't think I can spot anywhere that you would check the
>>>>>> other bits which need to be zero in extended EVEX. Nor Improper use
>>>>>> of EVEX.x4 in certain pre-existing encodings (S/G insns at least;
>>>>>> perhaps all
>>>> others are okay).
>>>>>
>>>>> Sorry, I can't get you here, what are S/G insns, could you provide
>>>>> more
>>>> details here, thanks.
>>>>
>>>> S/G is scatter/gather (i.e. AVX2 and AVX512).
>>>>
>>> I think you mean EVEX.V4, scatter/gather has VSIB which needs to reuse
>>> this bit (EVEX.x4 is EVEX.p[10] which is fixed value 1), For our current code
>> we will reassign that bit and now I changed it to check the upper 16 registers
>> of GPR32 , do you think it is ok?
>>>
>>> @@ -4252,7 +4252,7 @@ build_apx_evex_prefix (void)
>>>    if (i.rex2 & REX_R)
>>>      i.vex.bytes[1] &= 0xef;
>>>    if (i.vex.register_specifier
>>> -      && register_number (i.vex.register_specifier) > 0xf)
>>> +      && (i.vex.register_specifier->reg_flags & RegRex2))
>>>      i.vex.bytes[3] &= 0xf7;
>>>    if (i.rex2 & REX_B)
>>>      i.vex.bytes[1] |= 0x08;
>>
>> First of all my comment was disassembly related; you stripped a little too
>> much context for this to remain visible here. And then I think I did mean
>> EVEX.x4 - as you say it needs to be fixed-1 in e.g. S/G insns, and the checking
>> thereof is what I'm missing.
>>
> Ok ,  I will drop the encoder changes, and add an X4 check when instruction has vex_vsib* type in decoder.

You understand though that I used the S/G insns as example only. I didn't do
a proper check whether any others might also be affected. In particular ones
not allowing for memory operands might be.

Jan