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

["Cui, Lili" <lili.cui@intel.com>]

> >> 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.
> 
OK, I'll try to add more checks, and add description for them.

Lili.