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

[Cui, Lili]

> >>>>> 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.
> 

Done. Here is the Bugzilla https://sourceware.org/bugzilla/show_bug.cgi?id=32171

Thanks,
Lili.

> 
> Thanks.
> 
> 
> > Leaving mixed state is the worst of all
> >> options, imo.
> 
> ... leaving mixed state?
> 
> Jan