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

[H.J. Lu]

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.
>
> Lili.
>
> > Jan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20240912/7e09b57f/attachment.htm>