[PATCH] x86/APX: Don't promote AVX512 instructions out of APX spec

[H.J. Lu]

On Mon, Sep 16, 2024 at 2:38 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 16.09.2024 08:32, H.J. Lu wrote:
> > On Mon, Sep 16, 2024 at 2:01 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 16.09.2024 01:38, H.J. Lu wrote:
> >>> V{BROADCAST,EXTRACT,INSERT}{F,I}128 and VROUND{P,S}{S,D} aren't promoted
> >>> to support EGPR in APX spec.  Don't promote them out of APX spec.
> >>
> >> As previously indicated - I disagree with outright removal. If you want
> >> to have a strict mode, which compilers may want to enable, that's fine.
> >
> > There is no need to allow them.
>
> "Them" being what in this context? And regardless of the answer, this

"them" are these invalid EGPR instructions.

> likely will end up being your personal view, which others may or may
> not agree with.
>
> >> For hand-written assembly (possibly including inline assembly, yet there
> >
> > Adding them doesn't solve the inline assembly issue.  By default, GCC
> > doesn't allow EGPR in asm statements.  This option is needed to enable
> > EGPR in asm statements:
> >
> > ‘-mapx-inline-asm-use-gpr32’
> >      For inline asm support with APX, by default the EGPR feature was
> >      disabled to prevent potential illegal instruction with EGPR occurs.
> >      To invoke egpr usage in inline asm, use new compiler option
> >      -mapx-inline-asm-use-gpr32 and user should ensure the instruction
> >      supports EGPR.
>
> And with that option in use, said insns may end up failing to
> assemble. In a manner one may call random, as it'll depend on the
> compiler's register selection.

That is why there are "user should ensure the instruction supports EGPR."

> >> are sharp edges there) we ought to aid programmers. We aren't obliged
> >> to follow the spec to the letter, especially when the spec itself can be
> >
> > A spec is a spec even though you don't agreed with it.  We should follow
> > the APX spec.
>
> We need to do all the spec says, yes. The spec doesn't prevent us
> from doing more though, as long as it's compatible / functionally
> correct.

Re-encode APX instructions with non-APX encoding is OK.  But
we shouldn't add invalid EGPR instructions per APX spec.

-- 
H.J.