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

[H.J. Lu]

On Fri, Sep 13, 2024, 3:39 AM H.J. Lu <hjl.tools@gmail.com> wrote:

> On Thu, Sep 12, 2024, 6:08 PM Jan Beulich <jbeulich@suse.com> wrote:
>
>> 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 ...
>>
>
> 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.


> Thanks.
>
>
>> > Leaving mixed state is the worst of all
>> >> options, imo.
>>
>> ... leaving mixed state?
>>
>> Jan
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20240913/dfae0902/attachment.htm>