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

[H.J. Lu]

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.

Leaving mixed state is the worst of all
> options, imo.
>
> Jan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20240912/171b2c96/attachment-0001.htm>