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

[Jan Beulich]

On 12.09.2024 12:05, H.J. Lu wrote:
> On Thu, Sep 12, 2024, 5:30 PM Jan Beulich <jbeulich@suse.com> wrote:
> 
>> 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).
> 
> We really shouldn't do that.

I'm sorry, but your reply is ambiguous: We really shouldn't do what? The
promotions? (In which case: Why do objections appear only now, when much
of this is already in a release?) The undo? Or ...

> Leaving mixed state is the worst of all
>> options, imo.

... leaving mixed state?

Jan