[PATCH 2/8] Support APX GPR32 with extend evex prefix
Cui, Lili
lili.cui@intel.com
Wed Oct 18 11:30:37 GMT 2023
More information about the Binutils mailing list
Wed Oct 18 11:30:37 GMT 2023
- Previous message (by thread): [PATCH 2/8] Support APX GPR32 with extend evex prefix
- Next message (by thread): [PATCH 2/8] Support APX GPR32 with extend evex prefix
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> >> 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.
- Previous message (by thread): [PATCH 2/8] Support APX GPR32 with extend evex prefix
- Next message (by thread): [PATCH 2/8] Support APX GPR32 with extend evex prefix
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Binutils mailing list