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

[Cui, Lili]

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Wednesday, February 5, 2025 10:43 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 10:41, Jan Beulich wrote:
> > 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)?
> 
> It looks to be the latter. In v2 I'm now converting three of the four .byte
> to .insn in x86-64-apx-evex-promoted-bad. The one that cannot be converted
> is where EVEX.U is intended to be zero, when - afaict - that's neither
> expressable the APX way nor the AVX10/256 one. I also don't see how it could
> sensibly be expressed.
> 

Yes, I mean this one.  I also don't have any good ideas now. Let's deal with it later.

Lili.

> Jan