FW: [PATCH 3/8] Add tests for APX GPR32 with extend evex prefix

[Jan Beulich]

On 18.10.2023 04:32, Cui, Lili wrote:
>>>>> --- a/gas/testsuite/gas/i386/x86-64-inval-movbe.s
>>>>> +++ b/gas/testsuite/gas/i386/x86-64-inval-movbe.s
>>>>> @@ -1,5 +1,6 @@
>>>>>  # Check illegal movbe in 64bit mode.
>>>>>  	.text
>>>>> +	.arch .noapx_f
>>>>>  foo:
>>>>>  	movbe	(%rcx),%bl
>>>>>  	movbe	%ecx,%ebx
>>>>
>>>> I don't understand the need for this addition (and hence for the need
>>>> to change the test's expecations). Like was mentioned on the original
>>>> AVX10 series, tests like this shall not need modification, or else it
>>>> indicates people's code also may need ".arch .noapx_f" additions,
>>>> which I'm sure you agree may not be required. Finally, if testcase
>>>> expecations like the above would be needed anywhere, please
>>>> generalize them such that a similar mere addition of a line doesn't
>>>> require the entire test to be touched. Here this means that while for
>>>> the diagnostics you of course want exact line number matches, for the
>>>> actual listing line numbers don't don't need matching individually.
>>>>
>>>
>>> Agree with you, but movbe is special, movbe didn't support reg to reg
>> before, but APX enable it. so I added .arch .noapx_f for this invalid test.
>>
>> To be honest I didn't really notice this difference so far. That's somewhat ugly,
>> because people mistakenly using a reg->reg form would suddenly get an EVEX
>> encoding rather than an error. This will need some further thought; please
>> mention the "anomaly" explicitly in the description of the respective patch.
>>
> SPEC:
> Note: The promoted versions of MOVBE will be extended to include the “MOVBE reg1,
> reg2” form (namely, the ModRM.Mod = 3 case) for both opcodes 0xF0 and 0xF1. This
> extension makes the promotion of BSWAP for NDD support unnecessary.
> 
> I'll add a description of movbe to the patch 2/8 changelog. 

Thanks. I did deduce the connection to BSWAP on the way home yesterday. Which
made me come up with a (spec) question: Wouldn't it make sense to name these
reg->reg forms BSWAP, not MOVBE? It doesn't really matter that they use the
same encoding as the MOVBE (then mem-only) forms. That would then eliminate
the concern I raised.

As to 2/8: I received two v2 thereof, with different titles, and a v2 of 3/8.
But nothing else. The list archives match this. I may take a brief look, but
really I'll await a full v2 submission for a proper new review round.

Jan