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

[Jan Beulich]

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.

Jan