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

[H.J. Lu]

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.

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/17ee3405/attachment-0001.htm>