[PATCH v2 0/8] Support Intel APX EGPR

[Jan Beulich]

On 06.11.2023 15:20, Cui, Lili wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Monday, November 6, 2023 3:30 PM
>>
>> On 03.11.2023 17:42, Cui, Lili wrote:
>>> But if we want to merge bextr's vex and evex formats, we need to
>>> support BMI&(BMI |( APX_F&x64))
>>
>> Maybe more like BMI&(<tbd>|APX_F), with further work (which I was
>> considering
>> anyway) towards x64 becoming a prereq to the increasing number of 64-bit-
>> only features? (The <tbd> may well be BMI as you suggest, even if that reads a
>> little odd.
>>
> 
> Yes, most VEX instructions don't require x64, but apx_f is x64 based. If the format "BMI&(BMI |( APX_F&x64))"  is complicated to implement or looks ugly, maybe we can handle x64 uniformly for apx_f in tc-i386.c.

Well, some adjustment is needed there anyway, at the very least for the
equivalent of e.g. the present handling of AVX|AVX512F or FMA|AVX512F.
The goal wants to be to balance the amount of special casing code against
complications in representing data in the opcode table. One question I
have is: In how far is it necessary to actually represent APX_F in the
BMI templates? There are two things triggering use of the EVEX encoding,
iirc: Use of an extended register or NF. Use of an extended register is
itself already dependent upon APX_F, and whatever the representation of
NF is going to be, its parsing could be made dependent upon APX_F, too.
No (strong) need then for the template to enforce APX_F yet another time,
hopefully.

Jan