[PATCH] x86/APX: make .insn extended-EVEX capable

[Cui, Lili]

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Wednesday, February 5, 2025 5:42 PM
> To: Cui, Lili <lili.cui@intel.com>
> Cc: H.J. Lu <hjl.tools@gmail.com>; Jiang, Haochen
> <haochen.jiang@intel.com>; Binutils <binutils@sourceware.org>
> Subject: Re: [PATCH] x86/APX: make .insn extended-EVEX capable
> 
> On 05.02.2025 08:12, Cui, Lili wrote:
> >> -----Original Message-----
> >> From: Jan Beulich <jbeulich@suse.com>
> >> Sent: Monday, February 3, 2025 7:34 PM
> >>
> >> So far tricks had to be played to use .insn to encode extended-EVEX
> >> insns; the
> >> X4 bit couldn't be controlled at all. Extend the syntax just enough
> >> to cover all features, taking care to reject invalid feature
> >> combinations (albeit aiming at being as lax there as possible, to
> >> offer users as much flexibility as we can - we don't, after all, know what
> future will bring).
> >
> > Nice to have this patch, but we still can't change X4 arbitrarily, especially for
> those special invalid test cases. Hopefully in the future .insn can support
> changing all bits of the EVEX prefix, so .byte can be completely replaced.
> 
> Hmm, I'm confused: Doesn't the new testcase demonstrate that X4 can now
> be controlled? Can you give an example where things still don't work for you?
> Or do you maybe mean U rather than X4 (as X4 is only one of the meanings U
> has)?
> 

Maybe I'm wrong, I haven't tested it with your patch. I think we cannot handle this case in x86-64-apx-evex-promoted-bad.s. we want to set P[10] to 0.

        #VSIB vpgatherqq (%rbp,%zmm17,8),%zmm16{%k1} set EVEX.P[10] == 0
        .byte 0x62, 0xe2, 0xf9, 0x41, 0x91, 0x84, 0xcd
        .byte 0xff

Lili.

> Jan