[PATCH v2 0/8] Support Intel APX EGPR

[Cui, Lili]

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Monday, November 6, 2023 10:45 PM
> To: Cui, Lili <lili.cui@intel.com>
> Cc: Lu, Hongjiu <hongjiu.lu@intel.com>; ccoutant@gmail.com;
> binutils@sourceware.org
> Subject: Re: [PATCH v2 0/8] Support Intel APX EGPR
> 
> 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.
> 

In [patch 2/8] Support APX GPR32 with extend evex prefix, I only merged AMX's vex and evex formats (both vex and evex require x64), due to x64 reasons, BMI and other VEX instructions listed in 3.1.5 are not merged yet.
NDD also triggers EVEX encoding. There are some VEX instructions that support NF, their vex and evex cannot be merged.

Lili.