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

[Cui, Lili]

> -----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.

Lili.