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

[Jan Beulich]

On 12.09.2024 10:26, H.J. Lu wrote:
> On Thu, Sep 12, 2024, 3:47 PM Cui, Lili <lili.cui@intel.com> wrote:
> 
>>> Subject: Re: [PATCH 3/5] x86/APX: VMOVDQ{A,U} can also be expressed
>>>
>>> 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.
>>>
>>
>> Normally, binutils always downgrade EVEX code to VEX or shorter code by
>> default, but upgrading the wrong VEX to another EVEX instruction by default
>> will give people an unexpected first impression, since the apx spec
>> indicates that this is illegal.
>>
> 
> I agreed that it's a bad idea.
> 
> I am worried that this promotion will become more and more common, laying
>> hidden dangers, and eventually it will get out of control.

Well, I certainly don't expect similar promotions to occur very often (i.e.
in the future). As to what is done for APX - imo we should either complete
it, or undo what was previously done (despite there not having been any
real objections back at the time). Leaving mixed state is the worst of all
options, imo.

Jan