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

[Jan Beulich]

On 13.09.2024 05:43, Cui, Lili wrote:
>>>>>>> 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 ...
>>
>> Lili, please open an assembler bug for
>> all APX instructions which are promoted
>> by assembler, but not in the APX spec.
>>
>> Please run xed on binutils APX tests to
>> find out which instructions are rejected by xed.
>>
> 
> Done. Here is the Bugzilla https://sourceware.org/bugzilla/show_bug.cgi?id=32171

As indicated - we may want to have a "compiler" and a "hand written
assembly" mode. I would agree that for the former complaining (at
least warning) may be desirable. For the latter I think we ought to
aid programmers, though. If either of you is going to be at the
Cauldron in Prague, we could talk about this some there.

Jan