[PATCH 3/5] x86/APX: VMOVDQ{A,U} can also be expressed

[Jan Beulich]

On 11.09.2024 09:50, Cui, Lili wrote:
>> Interestingly unlike VROUND{P,S}{S,D} and VPERM{F,I}128, but like
>> V{BROADCAST,EXTRACT,INSERT}{F,I}128 they weren't even present in the x86-
>> 64-apx-egpr-inval testcase, hence why I overlooked that these, too, can be
>> encoded, (once again) using suitable AVX512F counterparts.
>>
> 
> I found some of our previous discussions. It would be better if these optimizations could be put under the option instead of by default.
> 
> 1. The compiler will do this during the backend instruction selection phase. Binutils should only do instruction translation, not instruction selection.

I'm afraid this again takes the compiler-only perspective. Please always
keep in mind that hand-written assembly is where any of this matters. If
we want ...

> 2. We can only convert some instructions, not all instructions. When users use eGPR-s illegally, some will report an error, while others will not, which is very confusing.
> 3. Binutils needs to report errors for illegal instructions to ensure the correctness of the compiler.

... a mode like this, we need an extra flag the compiler passes us.
That could be the existing -f, requiring that to be made work first.
This would have the advantage of asm() constructs then being treatable
like hand-written assembly (once suitably made work), while other code
could be checked as you say.

Right now the assumption is for the compiler to emit sane code.

> 4. I don't know if there are special cases where gcc doesn't want EVEX to be generated.

If such a need existed, insns would need marking accordingly by e.g.
pseudo prefixes ({vex} / {vex3} for the particular insns this patch is
about.

Jan