<div dir="auto"><div dir="auto">On Fri, Sep 13, 2024, 3:39 AM H.J. Lu <<a href="mailto:hjl.tools@gmail.com">hjl.tools@gmail.com</a>> wrote:<br></div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto">On Thu, Sep 12, 2024, 6:08 PM Jan Beulich <<a href="mailto:jbeulich@suse.com" target="_blank" rel="noreferrer">jbeulich@suse.com</a>> wrote:<br></div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 12.09.2024 12:05, H.J. Lu wrote:<br>
> On Thu, Sep 12, 2024, 5:30 PM Jan Beulich <<a href="mailto:jbeulich@suse.com" rel="noreferrer noreferrer" target="_blank">jbeulich@suse.com</a>> wrote:<br>
> <br>
>> On 12.09.2024 10:26, H.J. Lu wrote:<br>
>>> On Thu, Sep 12, 2024, 3:47 PM Cui, Lili <<a href="mailto:lili.cui@intel.com" rel="noreferrer noreferrer" target="_blank">lili.cui@intel.com</a>> wrote:<br>
>>><br>
>>>>> Subject: Re: [PATCH 3/5] x86/APX: VMOVDQ{A,U} can also be expressed<br>
>>>>><br>
>>>>> On 11.09.2024 09:50, Cui, Lili wrote:<br>
>>>>>>> Interestingly unlike VROUND{P,S}{S,D} and VPERM{F,I}128, but like<br>
>>>>>>> V{BROADCAST,EXTRACT,INSERT}{F,I}128 they weren't even present in the<br>
>>>>>>> x86- 64-apx-egpr-inval testcase, hence why I overlooked that these,<br>
>>>>>>> too, can be encoded, (once again) using suitable AVX512F<br>
>> counterparts.<br>
>>>>>>><br>
>>>>>><br>
>>>>>> I found some of our previous discussions. It would be better if these<br>
>>>>> optimizations could be put under the option instead of by default.<br>
>>>>>><br>
>>>>>> 1. The compiler will do this during the backend instruction selection<br>
>>>> phase.<br>
>>>>> Binutils should only do instruction translation, not instruction<br>
>>>> selection.<br>
>>>>><br>
>>>>> I'm afraid this again takes the compiler-only perspective. Please<br>
>> always<br>
>>>> keep in<br>
>>>>> mind that hand-written assembly is where any of this matters. If we<br>
>> want<br>
>>>> ...<br>
>>>>><br>
>>>>>> 2. We can only convert some instructions, not all instructions. When<br>
>>>> users use<br>
>>>>> eGPR-s illegally, some will report an error, while others will not,<br>
>>>> which is very<br>
>>>>> confusing.<br>
>>>>>> 3. Binutils needs to report errors for illegal instructions to ensure<br>
>>>> the<br>
>>>>> correctness of the compiler.<br>
>>>>><br>
>>>>> ... a mode like this, we need an extra flag the compiler passes us.<br>
>>>>> That could be the existing -f, requiring that to be made work first.<br>
>>>>> This would have the advantage of asm() constructs then being treatable<br>
>>>> like<br>
>>>>> hand-written assembly (once suitably made work), while other code could<br>
>>>> be<br>
>>>>> checked as you say.<br>
>>>>><br>
>>>>> Right now the assumption is for the compiler to emit sane code.<br>
>>>>><br>
>>>>>> 4. I don't know if there are special cases where gcc doesn't want EVEX<br>
>>>> to be<br>
>>>>> generated.<br>
>>>>><br>
>>>>> If such a need existed, insns would need marking accordingly by e.g.<br>
>>>>> pseudo prefixes ({vex} / {vex3} for the particular insns this patch is<br>
>>>> about.<br>
>>>>><br>
>>>><br>
>>>> Normally, binutils always downgrade EVEX code to VEX or shorter code by<br>
>>>> default, but upgrading the wrong VEX to another EVEX instruction by<br>
>> default<br>
>>>> will give people an unexpected first impression, since the apx spec<br>
>>>> indicates that this is illegal.<br>
>>>><br>
>>><br>
>>> I agreed that it's a bad idea.<br>
>>><br>
>>> I am worried that this promotion will become more and more common, laying<br>
>>>> hidden dangers, and eventually it will get out of control.<br>
>><br>
>> Well, I certainly don't expect similar promotions to occur very often (i.e.<br>
>> in the future). As to what is done for APX - imo we should either complete<br>
>> it, or undo what was previously done (despite there not having been any<br>
>> real objections back at the time).<br>
> <br>
> We really shouldn't do that.<br>
<br>
I'm sorry, but your reply is ambiguous: We really shouldn't do what? The<br>
promotions? (In which case: Why do objections appear only now, when much<br>
of this is already in a release?) The undo? Or ...<br></blockquote></div><div dir="auto"><br></div><div dir="auto">Lili, please open an assembler bug for</div><div dir="auto">all APX instructions which are promoted</div><div dir="auto">by assembler, but not in the APX spec.</div></div></blockquote></div><div dir="auto"><br></div><div dir="auto">Please run xed on binutils APX tests to</div><div dir="auto">find out which instructions are rejected by xed.</div><div dir="auto"><br></div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto"><br></div><div dir="auto">Thanks.</div><div dir="auto"><br></div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> Leaving mixed state is the worst of all<br>
>> options, imo.<br>
<br>
... leaving mixed state?<br>
<br>
Jan<br><br><br>
</blockquote></div></div>
</blockquote></div></div>