diff mbox series

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

Message ID CAMe9rOo0S4dpx4XZf5iw2FnRDC26N38Zr9ZUbC1_ngmyn1bo1A@mail.gmail.com
State New
Headers
Series x86/APX: Don't promote AVX512 instructions out of APX spec |

Checks

Context Check Description
linaro-tcwg-bot/tcwg_binutils_build--master-arm success Build passed
linaro-tcwg-bot/tcwg_binutils_build--master-aarch64 success Build passed
linaro-tcwg-bot/tcwg_binutils_check--master-aarch64 success Test passed
linaro-tcwg-bot/tcwg_binutils_check--master-arm success Test passed

Commit Message

H.J. Lu Sept. 15, 2024, 11:38 p.m. UTC 
  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.

Comments

Jan Beulich Sept. 16, 2024, 6:01 a.m. UTC | #1 
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.
For hand-written assembly (possibly including inline assembly, yet there
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
considered questionable, as to not properly promoting all existing
insns (which surely would have been possible from a purely technical
perspective).

As an aside,
- such a commit imo likely would want to mention the commits it 
  (effectively) reverts (the need for which will disappear when the
  effect is limited to said "strict" mode),
- I'm struggling with the purpose of the additions to the
  x86-64-apx-egpr-inval testcase, with the use of ".arch default"
  there.

Jan
H.J. Lu Sept. 16, 2024, 6:32 a.m. UTC | #2 
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.

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

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

> considered questionable, as to not properly promoting all existing
> insns (which surely would have been possible from a purely technical
> perspective).
>
> As an aside,
> - such a commit imo likely would want to mention the commits it
>   (effectively) reverts (the need for which will disappear when the
>   effect is limited to said "strict" mode),

I will update the commit message with

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.  This
commit effectively reverted:

ec3babb8c10 x86/APX: V{BROADCAST,EXTRACT,INSERT}{F,I}128 can also be expressed
5a635f1f59a x86/APX: VROUND{P,S}{S,D} encodings require AVX512{F,VL}
eea4357967b x86/APX: VROUND{P,S}{S,D} can generally be encoded

> - I'm struggling with the purpose of the additions to the
>   x86-64-apx-egpr-inval testcase, with the use of ".arch default"
>   there.

There are

.arch default
.arch .noapx_f

a few lines before.  ".arch default" restores the default.
Jan Beulich Sept. 16, 2024, 6:38 a.m. UTC | #3 
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
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.

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

Jan
H.J. Lu Sept. 16, 2024, 6:46 a.m. UTC | #4 
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.
Jan Beulich Sept. 16, 2024, 11:53 a.m. UTC | #5 
On 16.09.2024 08:46, H.J. Lu wrote:
> 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.

This is fine as an optimization, sure.

> But we shouldn't add invalid EGPR instructions per APX spec.

You continue to say so without providing any good reason. What's wrong
with going beyond the spec and helping the user at least a little to
get past some of the oddities of the spec? As it stands I remain
unconvinced of this step backwards, and hence the change shouldn't be
put in. I'm not going to exclude though that with appropriate
reasoning I might change my mind.

Jan
H.J. Lu Sept. 16, 2024, 1:25 p.m. UTC | #6 
On Mon, Sep 16, 2024 at 7:53 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 16.09.2024 08:46, H.J. Lu wrote:
> > 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.
>
> This is fine as an optimization, sure.
>
> > But we shouldn't add invalid EGPR instructions per APX spec.
>
> You continue to say so without providing any good reason. What's wrong
> with going beyond the spec and helping the user at least a little to
> get past some of the oddities of the spec? As it stands I remain
> unconvinced of this step backwards, and hence the change shouldn't be
> put in. I'm not going to exclude though that with appropriate
> reasoning I might change my mind.

Following APX spec is a very good reason.  Compilers always
generate valid APX instructions.  Assembly codes with EGPR
should also follow APX spec.  These bogus EGPR instructions
don't really help EGPR usage.
Cui, Lili Sept. 18, 2024, 1:15 a.m. UTC | #7 
> -----Original Message-----
> From: H.J. Lu <hjl.tools@gmail.com>
> Sent: Monday, September 16, 2024 9:26 PM
> To: Beulich, Jan <JBeulich@suse.com>
> Cc: Binutils <binutils@sourceware.org>; Cui, Lili <lili.cui@intel.com>
> Subject: Re: [PATCH] x86/APX: Don't promote AVX512 instructions out of APX
> spec
> 
> On Mon, Sep 16, 2024 at 7:53 PM Jan Beulich <jbeulich@suse.com> wrote:
> >
> > On 16.09.2024 08:46, H.J. Lu wrote:
> > > 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.
> >
> > This is fine as an optimization, sure.
> >
> > > But we shouldn't add invalid EGPR instructions per APX spec.
> >
> > You continue to say so without providing any good reason. What's wrong
> > with going beyond the spec and helping the user at least a little to
> > get past some of the oddities of the spec? As it stands I remain
> > unconvinced of this step backwards, and hence the change shouldn't be
> > put in. I'm not going to exclude though that with appropriate
> > reasoning I might change my mind.
> 
> Following APX spec is a very good reason.  Compilers always generate valid
> APX instructions.  Assembly codes with EGPR should also follow APX spec.
> These bogus EGPR instructions don't really help EGPR usage.
> 

For this type of optimization, we discussed this issue very carefully in the internal meeting last time, including different compilers, which is also the source of the opinions listed in my first post. For currently illegal usage, everyone recommends reporting errors.  I also specifically asked the authors of APX spec, and they also think that errors should be reported.

Thanks,
Lili.

> --
> H.J.
H.J. Lu Sept. 18, 2024, 1:44 a.m. UTC | #8 
On Wed, Sep 18, 2024 at 9:15 AM Cui, Lili <lili.cui@intel.com> wrote:
>
>
>
> > -----Original Message-----
> > From: H.J. Lu <hjl.tools@gmail.com>
> > Sent: Monday, September 16, 2024 9:26 PM
> > To: Beulich, Jan <JBeulich@suse.com>
> > Cc: Binutils <binutils@sourceware.org>; Cui, Lili <lili.cui@intel.com>
> > Subject: Re: [PATCH] x86/APX: Don't promote AVX512 instructions out of APX
> > spec
> >
> > On Mon, Sep 16, 2024 at 7:53 PM Jan Beulich <jbeulich@suse.com> wrote:
> > >
> > > On 16.09.2024 08:46, H.J. Lu wrote:
> > > > 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.
> > >
> > > This is fine as an optimization, sure.
> > >
> > > > But we shouldn't add invalid EGPR instructions per APX spec.
> > >
> > > You continue to say so without providing any good reason. What's wrong
> > > with going beyond the spec and helping the user at least a little to
> > > get past some of the oddities of the spec? As it stands I remain
> > > unconvinced of this step backwards, and hence the change shouldn't be
> > > put in. I'm not going to exclude though that with appropriate
> > > reasoning I might change my mind.
> >
> > Following APX spec is a very good reason.  Compilers always generate valid
> > APX instructions.  Assembly codes with EGPR should also follow APX spec.
> > These bogus EGPR instructions don't really help EGPR usage.
> >
>
> For this type of optimization, we discussed this issue very carefully in the internal meeting last time, including different compilers, which is also the source of the opinions listed in my first post. For currently illegal usage, everyone recommends reporting errors.  I also specifically asked the authors of APX spec, and they also think that errors should be reported.
>

I will check in my patch today.

Thanks.
H.J. Lu Sept. 20, 2024, 9:26 p.m. UTC | #9 
On Wed, Sep 18, 2024 at 9:44 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Wed, Sep 18, 2024 at 9:15 AM Cui, Lili <lili.cui@intel.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: H.J. Lu <hjl.tools@gmail.com>
> > > Sent: Monday, September 16, 2024 9:26 PM
> > > To: Beulich, Jan <JBeulich@suse.com>
> > > Cc: Binutils <binutils@sourceware.org>; Cui, Lili <lili.cui@intel.com>
> > > Subject: Re: [PATCH] x86/APX: Don't promote AVX512 instructions out of APX
> > > spec
> > >
> > > On Mon, Sep 16, 2024 at 7:53 PM Jan Beulich <jbeulich@suse.com> wrote:
> > > >
> > > > On 16.09.2024 08:46, H.J. Lu wrote:
> > > > > 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.
> > > >
> > > > This is fine as an optimization, sure.
> > > >
> > > > > But we shouldn't add invalid EGPR instructions per APX spec.
> > > >
> > > > You continue to say so without providing any good reason. What's wrong
> > > > with going beyond the spec and helping the user at least a little to
> > > > get past some of the oddities of the spec? As it stands I remain
> > > > unconvinced of this step backwards, and hence the change shouldn't be
> > > > put in. I'm not going to exclude though that with appropriate
> > > > reasoning I might change my mind.
> > >
> > > Following APX spec is a very good reason.  Compilers always generate valid
> > > APX instructions.  Assembly codes with EGPR should also follow APX spec.
> > > These bogus EGPR instructions don't really help EGPR usage.
> > >
> >
> > For this type of optimization, we discussed this issue very carefully in the internal meeting last time, including different compilers, which is also the source of the opinions listed in my first post. For currently illegal usage, everyone recommends reporting errors.  I also specifically asked the authors of APX spec, and they also think that errors should be reported.
> >
>
> I will check in my patch today.
>

I am backporting it to 2.43 branch.
Cui, Lili Sept. 23, 2024, 12:23 a.m. UTC | #10 
> > > > -----Original Message-----
> > > > From: H.J. Lu <hjl.tools@gmail.com>
> > > > Sent: Monday, September 16, 2024 9:26 PM
> > > > To: Beulich, Jan <JBeulich@suse.com>
> > > > Cc: Binutils <binutils@sourceware.org>; Cui, Lili
> > > > <lili.cui@intel.com>
> > > > Subject: Re: [PATCH] x86/APX: Don't promote AVX512 instructions
> > > > out of APX spec
> > > >
> > > > On Mon, Sep 16, 2024 at 7:53 PM Jan Beulich <jbeulich@suse.com> wrote:
> > > > >
> > > > > On 16.09.2024 08:46, H.J. Lu wrote:
> > > > > > 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.
> > > > >
> > > > > This is fine as an optimization, sure.
> > > > >
> > > > > > But we shouldn't add invalid EGPR instructions per APX spec.
> > > > >
> > > > > You continue to say so without providing any good reason. What's
> > > > > wrong with going beyond the spec and helping the user at least a
> > > > > little to get past some of the oddities of the spec? As it
> > > > > stands I remain unconvinced of this step backwards, and hence
> > > > > the change shouldn't be put in. I'm not going to exclude though
> > > > > that with appropriate reasoning I might change my mind.
> > > >
> > > > Following APX spec is a very good reason.  Compilers always
> > > > generate valid APX instructions.  Assembly codes with EGPR should also
> follow APX spec.
> > > > These bogus EGPR instructions don't really help EGPR usage.
> > > >
> > >
> > > For this type of optimization, we discussed this issue very carefully in the
> internal meeting last time, including different compilers, which is also the source
> of the opinions listed in my first post. For currently illegal usage, everyone
> recommends reporting errors.  I also specifically asked the authors of APX spec,
> and they also think that errors should be reported.
> > >
> >
> > I will check in my patch today.
> >
> 
> I am backporting it to 2.43 branch.
> 

This is indeed necessary.

Thanks,
Lili.

> --
> H.J.
Jan Beulich Sept. 23, 2024, 6:14 a.m. UTC | #11 
On 16.09.2024 15:25, H.J. Lu wrote:
> On Mon, Sep 16, 2024 at 7:53 PM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 16.09.2024 08:46, H.J. Lu wrote:
>>> 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.
>>
>> This is fine as an optimization, sure.
>>
>>> But we shouldn't add invalid EGPR instructions per APX spec.
>>
>> You continue to say so without providing any good reason. What's wrong
>> with going beyond the spec and helping the user at least a little to
>> get past some of the oddities of the spec? As it stands I remain
>> unconvinced of this step backwards, and hence the change shouldn't be
>> put in. I'm not going to exclude though that with appropriate
>> reasoning I might change my mind.
> 
> Following APX spec is a very good reason.

You still put it as if I asked to not follow the spec. I'm instead
arguing for going beyond the spec, without violating it in any way.

Elsewhere you're entirely fine, and even promoting going beyond
specs. All of AT&T syntax is in principle beyond the spec. There
is a pretty old one, yes, yet how it was extended over the years in
gas was entirely out-of-spec.

No - you're not going to get away with always bending rules / specs
in your own favor. You had no grounds to commit this change, and
you had even less grounds to backport it to 2.43. This will want
reverting. I indicated a middle ground where we could meet. If
you're not willing to compromise, what matters is the state of the
tree at the point where the disagreement started. That's an
unwritten rule you claimed in the past. Now it's time to also live
with it when you don't like it.

>  Compilers always
> generate valid APX instructions.  Assembly codes with EGPR
> should also follow APX spec.  These bogus EGPR instructions
> don't really help EGPR usage.

That's your view. My view is that the APX spec puts in place
unnecessary restrictions, which we ought to help overcome as much
as possible.

Jan
Cui, Lili Sept. 23, 2024, 7:51 a.m. UTC | #12 
> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Monday, September 23, 2024 2:15 PM
> To: H.J. Lu <hjl.tools@gmail.com>
> Cc: Binutils <binutils@sourceware.org>; Cui, Lili <lili.cui@intel.com>
> Subject: Re: [PATCH] x86/APX: Don't promote AVX512 instructions out of APX
> spec
> 
> On 16.09.2024 15:25, H.J. Lu wrote:
> > On Mon, Sep 16, 2024 at 7:53 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 16.09.2024 08:46, H.J. Lu wrote:
> >>> 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.
> >>
> >> This is fine as an optimization, sure.
> >>
> >>> But we shouldn't add invalid EGPR instructions per APX spec.
> >>
> >> You continue to say so without providing any good reason. What's
> >> wrong with going beyond the spec and helping the user at least a
> >> little to get past some of the oddities of the spec? As it stands I
> >> remain unconvinced of this step backwards, and hence the change
> >> shouldn't be put in. I'm not going to exclude though that with
> >> appropriate reasoning I might change my mind.
> >
> > Following APX spec is a very good reason.
> 
> You still put it as if I asked to not follow the spec. I'm instead arguing for going
> beyond the spec, without violating it in any way.
> 

Jan, I'm sorry that I didn't notice you checking in these patches at first, although I have been against this kind of promotion in the previous discussion. But it's really a bit radical to make this kind of out-of-spec promotion by default. Would you rather put them under options? After all, these conversions are very clever.

Thanks,
Lili.
Jan Beulich Sept. 23, 2024, 8:29 a.m. UTC | #13 
On 23.09.2024 09:51, Cui, Lili wrote:
> Jan, I'm sorry that I didn't notice you checking in these patches at first, although I have been against this kind of promotion in the previous discussion. But it's really a bit radical to make this kind of out-of-spec promotion by default. Would you rather put them under options? After all, these conversions are very clever.

I continue to think they want doing by default, with possibly a way to turn
them off (compiler mode) and/or diagnose them (perhaps no more than "info"
level).

Jan
Cui, Lili Sept. 23, 2024, 11:14 a.m. UTC | #14 
> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Monday, September 23, 2024 4:30 PM
> To: Cui, Lili <lili.cui@intel.com>
> Cc: Binutils <binutils@sourceware.org>; H.J. Lu <hjl.tools@gmail.com>
> Subject: Re: [PATCH] x86/APX: Don't promote AVX512 instructions out of APX
> spec
> 
> On 23.09.2024 09:51, Cui, Lili wrote:
> > Jan, I'm sorry that I didn't notice you checking in these patches at first,
> although I have been against this kind of promotion in the previous discussion.
> But it's really a bit radical to make this kind of out-of-spec promotion by default.
> Would you rather put them under options? After all, these conversions are very
> clever.
> 
> I continue to think they want doing by default, with possibly a way to turn them
> off (compiler mode) and/or diagnose them (perhaps no more than "info"
> level).
> 

The benefit of this optimization is that when the hand-written assembler makes a mistake in writing few VEX instructions, we can promote it to the EVEX instructions. The cost is to let the compiler add a separate option when compiling or define different behaviors for the compiler and the hand-written assembler mode (If there is a way to do this, inline assembler and hand-written assembly behavior is inconsistent, this inconsistent behavior will confuse people). Other compilers also strictly enforce errors for this illegal Egpr usage. We cannot promote all illegal Egpr usage, if there is such an improvement, it may be worth making such a change.
 
Thanks,
Lili.

> Jan
Jan Beulich Sept. 23, 2024, 11:22 a.m. UTC | #15 
On 23.09.2024 13:14, Cui, Lili wrote:
> 
> 
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Monday, September 23, 2024 4:30 PM
>> To: Cui, Lili <lili.cui@intel.com>
>> Cc: Binutils <binutils@sourceware.org>; H.J. Lu <hjl.tools@gmail.com>
>> Subject: Re: [PATCH] x86/APX: Don't promote AVX512 instructions out of APX
>> spec
>>
>> On 23.09.2024 09:51, Cui, Lili wrote:
>>> Jan, I'm sorry that I didn't notice you checking in these patches at first,
>> although I have been against this kind of promotion in the previous discussion.
>> But it's really a bit radical to make this kind of out-of-spec promotion by default.
>> Would you rather put them under options? After all, these conversions are very
>> clever.
>>
>> I continue to think they want doing by default, with possibly a way to turn them
>> off (compiler mode) and/or diagnose them (perhaps no more than "info"
>> level).
>>
> 
> The benefit of this optimization is that when the hand-written assembler makes a mistake in writing few VEX instructions, we can promote it to the EVEX instructions. The cost is to let the compiler add a separate option when compiling or define different behaviors for the compiler and the hand-written assembler mode (If there is a way to do this, inline assembler and hand-written assembly behavior is inconsistent, this inconsistent behavior will confuse people). Other compilers also strictly enforce errors for this illegal Egpr usage. We cannot promote all illegal Egpr usage, if there is such an improvement,

I'm relatively sure this could be arranged for in many of the cases, just not
with single-insn replacements. I didn't want to go _that_ far ...

Jan 

> it may be worth making such a change.
>  
> Thanks,
> Lili.
> 
>> Jan
H.J. Lu Sept. 23, 2024, 9:42 p.m. UTC | #16 
On Mon, Sep 23, 2024, 7:22 PM Jan Beulich <jbeulich@suse.com> wrote:

> On 23.09.2024 13:14, Cui, Lili wrote:
> >
> >
> >> -----Original Message-----
> >> From: Jan Beulich <jbeulich@suse.com>
> >> Sent: Monday, September 23, 2024 4:30 PM
> >> To: Cui, Lili <lili.cui@intel.com>
> >> Cc: Binutils <binutils@sourceware.org>; H.J. Lu <hjl.tools@gmail.com>
> >> Subject: Re: [PATCH] x86/APX: Don't promote AVX512 instructions out of
> APX
> >> spec
> >>
> >> On 23.09.2024 09:51, Cui, Lili wrote:
> >>> Jan, I'm sorry that I didn't notice you checking in these patches at
> first,
> >> although I have been against this kind of promotion in the previous
> discussion.
> >> But it's really a bit radical to make this kind of out-of-spec
> promotion by default.
> >> Would you rather put them under options? After all, these conversions
> are very
> >> clever.
> >>
> >> I continue to think they want doing by default, with possibly a way to
> turn them
> >> off (compiler mode) and/or diagnose them (perhaps no more than "info"
> >> level).
> >>
> >
> > The benefit of this optimization is that when the hand-written assembler
> makes a mistake in writing few VEX instructions, we can promote it to the
> EVEX instructions. The cost is to let the compiler add a separate option
> when compiling or define different behaviors for the compiler and the
> hand-written assembler mode (If there is a way to do this, inline assembler
> and hand-written assembly behavior is inconsistent, this inconsistent
> behavior will confuse people). Other compilers also strictly enforce errors
> for this illegal Egpr usage. We cannot promote all illegal Egpr usage, if
> there is such an improvement,
>
> I'm relatively sure this could be arranged for in many of the cases, just
> not
> with single-insn replacements. I didn't want to go _that_ far ...
>

Assembly programmers will write assmebly codes
following the spec so that the source will work for
all compilers/assemblers.  It makes little senses to
add these instructions to GNU assembler, especially by default.


> Jan
>
> > it may be worth making such a change.
> >
> > Thanks,
> > Lili.
> >
> >> Jan
>
>
>
Jan Beulich Sept. 24, 2024, 10:04 a.m. UTC | #17 
On 23.09.2024 23:42, H.J. Lu wrote:
> On Mon, Sep 23, 2024, 7:22 PM Jan Beulich <jbeulich@suse.com> wrote:
>> On 23.09.2024 13:14, Cui, Lili wrote:
>>>> -----Original Message-----
>>>> From: Jan Beulich <jbeulich@suse.com>
>>>> Sent: Monday, September 23, 2024 4:30 PM
>>>>
>>>> On 23.09.2024 09:51, Cui, Lili wrote:
>>>>> Jan, I'm sorry that I didn't notice you checking in these patches at
>> first,
>>>> although I have been against this kind of promotion in the previous
>> discussion.
>>>> But it's really a bit radical to make this kind of out-of-spec
>> promotion by default.
>>>> Would you rather put them under options? After all, these conversions
>> are very
>>>> clever.
>>>>
>>>> I continue to think they want doing by default, with possibly a way to
>> turn them
>>>> off (compiler mode) and/or diagnose them (perhaps no more than "info"
>>>> level).
>>>>
>>>
>>> The benefit of this optimization is that when the hand-written assembler
>> makes a mistake in writing few VEX instructions, we can promote it to the
>> EVEX instructions. The cost is to let the compiler add a separate option
>> when compiling or define different behaviors for the compiler and the
>> hand-written assembler mode (If there is a way to do this, inline assembler
>> and hand-written assembly behavior is inconsistent, this inconsistent
>> behavior will confuse people). Other compilers also strictly enforce errors
>> for this illegal Egpr usage. We cannot promote all illegal Egpr usage, if
>> there is such an improvement,
>>
>> I'm relatively sure this could be arranged for in many of the cases, just
>> not
>> with single-insn replacements. I didn't want to go _that_ far ...
> 
> Assembly programmers will write assmebly codes
> following the spec so that the source will work for
> all compilers/assemblers.  It makes little senses to
> add these instructions to GNU assembler, especially by default.

Well, I continue to disagree, but I guess I'll leave it at that. Just
to be done here, even if really I shouldn't be letting you get through
once again with playing against the rules. For the future be forewarned,
though: I may not again first discuss what to do, I may simply revert
commits of yours that were done while there were pending objections, or
when you didn't even give people time to object.

Jan
H.J. Lu Sept. 24, 2024, 10:21 a.m. UTC | #18 
On Tue, Sep 24, 2024 at 6:04 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 23.09.2024 23:42, H.J. Lu wrote:
> > On Mon, Sep 23, 2024, 7:22 PM Jan Beulich <jbeulich@suse.com> wrote:
> >> On 23.09.2024 13:14, Cui, Lili wrote:
> >>>> -----Original Message-----
> >>>> From: Jan Beulich <jbeulich@suse.com>
> >>>> Sent: Monday, September 23, 2024 4:30 PM
> >>>>
> >>>> On 23.09.2024 09:51, Cui, Lili wrote:
> >>>>> Jan, I'm sorry that I didn't notice you checking in these patches at
> >> first,
> >>>> although I have been against this kind of promotion in the previous
> >> discussion.
> >>>> But it's really a bit radical to make this kind of out-of-spec
> >> promotion by default.
> >>>> Would you rather put them under options? After all, these conversions
> >> are very
> >>>> clever.
> >>>>
> >>>> I continue to think they want doing by default, with possibly a way to
> >> turn them
> >>>> off (compiler mode) and/or diagnose them (perhaps no more than "info"
> >>>> level).
> >>>>
> >>>
> >>> The benefit of this optimization is that when the hand-written assembler
> >> makes a mistake in writing few VEX instructions, we can promote it to the
> >> EVEX instructions. The cost is to let the compiler add a separate option
> >> when compiling or define different behaviors for the compiler and the
> >> hand-written assembler mode (If there is a way to do this, inline assembler
> >> and hand-written assembly behavior is inconsistent, this inconsistent
> >> behavior will confuse people). Other compilers also strictly enforce errors
> >> for this illegal Egpr usage. We cannot promote all illegal Egpr usage, if
> >> there is such an improvement,
> >>
> >> I'm relatively sure this could be arranged for in many of the cases, just
> >> not
> >> with single-insn replacements. I didn't want to go _that_ far ...
> >
> > Assembly programmers will write assmebly codes
> > following the spec so that the source will work for
> > all compilers/assemblers.  It makes little senses to
> > add these instructions to GNU assembler, especially by default.
>
> Well, I continue to disagree, but I guess I'll leave it at that. Just
> to be done here, even if really I shouldn't be letting you get through
> once again with playing against the rules. For the future be forewarned,

You keep saying the rules.  What are the rules?

> though: I may not again first discuss what to do, I may simply revert
> commits of yours that were done while there were pending objections, or
> when you didn't even give people time to object.
>
> Jan
Jan Beulich Sept. 24, 2024, 10:52 a.m. UTC | #19 
On 24.09.2024 12:21, H.J. Lu wrote:
> On Tue, Sep 24, 2024 at 6:04 PM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 23.09.2024 23:42, H.J. Lu wrote:
>>> On Mon, Sep 23, 2024, 7:22 PM Jan Beulich <jbeulich@suse.com> wrote:
>>>> On 23.09.2024 13:14, Cui, Lili wrote:
>>>>>> -----Original Message-----
>>>>>> From: Jan Beulich <jbeulich@suse.com>
>>>>>> Sent: Monday, September 23, 2024 4:30 PM
>>>>>>
>>>>>> On 23.09.2024 09:51, Cui, Lili wrote:
>>>>>>> Jan, I'm sorry that I didn't notice you checking in these patches at
>>>> first,
>>>>>> although I have been against this kind of promotion in the previous
>>>> discussion.
>>>>>> But it's really a bit radical to make this kind of out-of-spec
>>>> promotion by default.
>>>>>> Would you rather put them under options? After all, these conversions
>>>> are very
>>>>>> clever.
>>>>>>
>>>>>> I continue to think they want doing by default, with possibly a way to
>>>> turn them
>>>>>> off (compiler mode) and/or diagnose them (perhaps no more than "info"
>>>>>> level).
>>>>>>
>>>>>
>>>>> The benefit of this optimization is that when the hand-written assembler
>>>> makes a mistake in writing few VEX instructions, we can promote it to the
>>>> EVEX instructions. The cost is to let the compiler add a separate option
>>>> when compiling or define different behaviors for the compiler and the
>>>> hand-written assembler mode (If there is a way to do this, inline assembler
>>>> and hand-written assembly behavior is inconsistent, this inconsistent
>>>> behavior will confuse people). Other compilers also strictly enforce errors
>>>> for this illegal Egpr usage. We cannot promote all illegal Egpr usage, if
>>>> there is such an improvement,
>>>>
>>>> I'm relatively sure this could be arranged for in many of the cases, just
>>>> not
>>>> with single-insn replacements. I didn't want to go _that_ far ...
>>>
>>> Assembly programmers will write assmebly codes
>>> following the spec so that the source will work for
>>> all compilers/assemblers.  It makes little senses to
>>> add these instructions to GNU assembler, especially by default.
>>
>> Well, I continue to disagree, but I guess I'll leave it at that. Just
>> to be done here, even if really I shouldn't be letting you get through
>> once again with playing against the rules. For the future be forewarned,
> 
> You keep saying the rules.  What are the rules?

It should go without saying that you cannot commit anything that has an
unresolved objection. And I've mentioned numerous times that especially
on potentially controversial changes you ought to allow a reasonable
amount of time between submitting and committing.

Jan
H.J. Lu Sept. 24, 2024, 10:58 a.m. UTC | #20 
On Tue, Sep 24, 2024, 6:53 PM Jan Beulich <jbeulich@suse.com> wrote:

> On 24.09.2024 12:21, H.J. Lu wrote:
> > On Tue, Sep 24, 2024 at 6:04 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 23.09.2024 23:42, H.J. Lu wrote:
> >>> On Mon, Sep 23, 2024, 7:22 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>>> On 23.09.2024 13:14, Cui, Lili wrote:
> >>>>>> -----Original Message-----
> >>>>>> From: Jan Beulich <jbeulich@suse.com>
> >>>>>> Sent: Monday, September 23, 2024 4:30 PM
> >>>>>>
> >>>>>> On 23.09.2024 09:51, Cui, Lili wrote:
> >>>>>>> Jan, I'm sorry that I didn't notice you checking in these patches
> at
> >>>> first,
> >>>>>> although I have been against this kind of promotion in the previous
> >>>> discussion.
> >>>>>> But it's really a bit radical to make this kind of out-of-spec
> >>>> promotion by default.
> >>>>>> Would you rather put them under options? After all, these
> conversions
> >>>> are very
> >>>>>> clever.
> >>>>>>
> >>>>>> I continue to think they want doing by default, with possibly a way
> to
> >>>> turn them
> >>>>>> off (compiler mode) and/or diagnose them (perhaps no more than
> "info"
> >>>>>> level).
> >>>>>>
> >>>>>
> >>>>> The benefit of this optimization is that when the hand-written
> assembler
> >>>> makes a mistake in writing few VEX instructions, we can promote it to
> the
> >>>> EVEX instructions. The cost is to let the compiler add a separate
> option
> >>>> when compiling or define different behaviors for the compiler and the
> >>>> hand-written assembler mode (If there is a way to do this, inline
> assembler
> >>>> and hand-written assembly behavior is inconsistent, this inconsistent
> >>>> behavior will confuse people). Other compilers also strictly enforce
> errors
> >>>> for this illegal Egpr usage. We cannot promote all illegal Egpr
> usage, if
> >>>> there is such an improvement,
> >>>>
> >>>> I'm relatively sure this could be arranged for in many of the cases,
> just
> >>>> not
> >>>> with single-insn replacements. I didn't want to go _that_ far ...
> >>>
> >>> Assembly programmers will write assmebly codes
> >>> following the spec so that the source will work for
> >>> all compilers/assemblers.  It makes little senses to
> >>> add these instructions to GNU assembler, especially by default.
> >>
> >> Well, I continue to disagree, but I guess I'll leave it at that. Just
> >> to be done here, even if really I shouldn't be letting you get through
> >> once again with playing against the rules. For the future be forewarned,
> >
> > You keep saying the rules.  What are the rules?
>
> It should go without saying that you cannot commit anything that has an
> unresolved objection. And I've mentioned numerous times that especially
>

Are you suggesting anyone can hold the project as hostage?

on potentially controversial changes you ought to allow a reasonable
> amount of time between submitting and committing.
>

I believe I am now doing that unless it is a very obvious fix.



> Jan
>
>
Jan Beulich Sept. 24, 2024, 11:19 a.m. UTC | #21 
On 24.09.2024 12:58, H.J. Lu wrote:
> On Tue, Sep 24, 2024, 6:53 PM Jan Beulich <jbeulich@suse.com> wrote:
> 
>> On 24.09.2024 12:21, H.J. Lu wrote:
>>> On Tue, Sep 24, 2024 at 6:04 PM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 23.09.2024 23:42, H.J. Lu wrote:
>>>>> On Mon, Sep 23, 2024, 7:22 PM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>> On 23.09.2024 13:14, Cui, Lili wrote:
>>>>>>>> -----Original Message-----
>>>>>>>> From: Jan Beulich <jbeulich@suse.com>
>>>>>>>> Sent: Monday, September 23, 2024 4:30 PM
>>>>>>>>
>>>>>>>> On 23.09.2024 09:51, Cui, Lili wrote:
>>>>>>>>> Jan, I'm sorry that I didn't notice you checking in these patches
>> at
>>>>>> first,
>>>>>>>> although I have been against this kind of promotion in the previous
>>>>>> discussion.
>>>>>>>> But it's really a bit radical to make this kind of out-of-spec
>>>>>> promotion by default.
>>>>>>>> Would you rather put them under options? After all, these
>> conversions
>>>>>> are very
>>>>>>>> clever.
>>>>>>>>
>>>>>>>> I continue to think they want doing by default, with possibly a way
>> to
>>>>>> turn them
>>>>>>>> off (compiler mode) and/or diagnose them (perhaps no more than
>> "info"
>>>>>>>> level).
>>>>>>>>
>>>>>>>
>>>>>>> The benefit of this optimization is that when the hand-written
>> assembler
>>>>>> makes a mistake in writing few VEX instructions, we can promote it to
>> the
>>>>>> EVEX instructions. The cost is to let the compiler add a separate
>> option
>>>>>> when compiling or define different behaviors for the compiler and the
>>>>>> hand-written assembler mode (If there is a way to do this, inline
>> assembler
>>>>>> and hand-written assembly behavior is inconsistent, this inconsistent
>>>>>> behavior will confuse people). Other compilers also strictly enforce
>> errors
>>>>>> for this illegal Egpr usage. We cannot promote all illegal Egpr
>> usage, if
>>>>>> there is such an improvement,
>>>>>>
>>>>>> I'm relatively sure this could be arranged for in many of the cases,
>> just
>>>>>> not
>>>>>> with single-insn replacements. I didn't want to go _that_ far ...
>>>>>
>>>>> Assembly programmers will write assmebly codes
>>>>> following the spec so that the source will work for
>>>>> all compilers/assemblers.  It makes little senses to
>>>>> add these instructions to GNU assembler, especially by default.
>>>>
>>>> Well, I continue to disagree, but I guess I'll leave it at that. Just
>>>> to be done here, even if really I shouldn't be letting you get through
>>>> once again with playing against the rules. For the future be forewarned,
>>>
>>> You keep saying the rules.  What are the rules?
>>
>> It should go without saying that you cannot commit anything that has an
>> unresolved objection. And I've mentioned numerous times that especially
> 
> Are you suggesting anyone can hold the project as hostage?

Of course not. But disagreements need resolving. If someone objects and
then doesn't any further participate in the resolution, the objection
will "expire" at some point. And of course it is possible to identify
objections as unsubstantiated, or for a maintainer to override a non-
maintainer's objection. But if, as in the case here, two equal
maintainters disagree, it is inappropriate to simply "force through"
one's view by committing stuff. In such (imo rare) cases where
agreement cannot otherwise be reached, arbitration may be needed. That
would imo typically mean involving Nick. I don't think it would have
required to go this far in the case here though, if only you had been
willing to actually provide a better (less arbitrary) justification for
the revert.

Jan
H.J. Lu Sept. 24, 2024, 9:05 p.m. UTC | #22 
On Tue, Sep 24, 2024 at 7:19 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 24.09.2024 12:58, H.J. Lu wrote:
> > On Tue, Sep 24, 2024, 6:53 PM Jan Beulich <jbeulich@suse.com> wrote:
> >
> >> On 24.09.2024 12:21, H.J. Lu wrote:
> >>> On Tue, Sep 24, 2024 at 6:04 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>
> >>>> On 23.09.2024 23:42, H.J. Lu wrote:
> >>>>> On Mon, Sep 23, 2024, 7:22 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>> On 23.09.2024 13:14, Cui, Lili wrote:
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Jan Beulich <jbeulich@suse.com>
> >>>>>>>> Sent: Monday, September 23, 2024 4:30 PM
> >>>>>>>>
> >>>>>>>> On 23.09.2024 09:51, Cui, Lili wrote:
> >>>>>>>>> Jan, I'm sorry that I didn't notice you checking in these patches
> >> at
> >>>>>> first,
> >>>>>>>> although I have been against this kind of promotion in the previous
> >>>>>> discussion.
> >>>>>>>> But it's really a bit radical to make this kind of out-of-spec
> >>>>>> promotion by default.
> >>>>>>>> Would you rather put them under options? After all, these
> >> conversions
> >>>>>> are very
> >>>>>>>> clever.
> >>>>>>>>
> >>>>>>>> I continue to think they want doing by default, with possibly a way
> >> to
> >>>>>> turn them
> >>>>>>>> off (compiler mode) and/or diagnose them (perhaps no more than
> >> "info"
> >>>>>>>> level).
> >>>>>>>>
> >>>>>>>
> >>>>>>> The benefit of this optimization is that when the hand-written
> >> assembler
> >>>>>> makes a mistake in writing few VEX instructions, we can promote it to
> >> the
> >>>>>> EVEX instructions. The cost is to let the compiler add a separate
> >> option
> >>>>>> when compiling or define different behaviors for the compiler and the
> >>>>>> hand-written assembler mode (If there is a way to do this, inline
> >> assembler
> >>>>>> and hand-written assembly behavior is inconsistent, this inconsistent
> >>>>>> behavior will confuse people). Other compilers also strictly enforce
> >> errors
> >>>>>> for this illegal Egpr usage. We cannot promote all illegal Egpr
> >> usage, if
> >>>>>> there is such an improvement,
> >>>>>>
> >>>>>> I'm relatively sure this could be arranged for in many of the cases,
> >> just
> >>>>>> not
> >>>>>> with single-insn replacements. I didn't want to go _that_ far ...
> >>>>>
> >>>>> Assembly programmers will write assmebly codes
> >>>>> following the spec so that the source will work for
> >>>>> all compilers/assemblers.  It makes little senses to
> >>>>> add these instructions to GNU assembler, especially by default.
> >>>>
> >>>> Well, I continue to disagree, but I guess I'll leave it at that. Just
> >>>> to be done here, even if really I shouldn't be letting you get through
> >>>> once again with playing against the rules. For the future be forewarned,
> >>>
> >>> You keep saying the rules.  What are the rules?
> >>
> >> It should go without saying that you cannot commit anything that has an
> >> unresolved objection. And I've mentioned numerous times that especially
> >
> > Are you suggesting anyone can hold the project as hostage?
>
> Of course not. But disagreements need resolving. If someone objects and
> then doesn't any further participate in the resolution, the objection
> will "expire" at some point. And of course it is possible to identify
> objections as unsubstantiated, or for a maintainer to override a non-
> maintainer's objection. But if, as in the case here, two equal
> maintainters disagree, it is inappropriate to simply "force through"
> one's view by committing stuff. In such (imo rare) cases where
> agreement cannot otherwise be reached, arbitration may be needed. That
> would imo typically mean involving Nick. I don't think it would have
> required to go this far in the case here though, if only you had been
> willing to actually provide a better (less arbitrary) justification for
> the revert.
>
> Jan

Assembly programmers will write APX assembly codes following the APX
spec so that the source will work for all compilers/assemblers.  This is a
good enough reason to me.
diff mbox series

Patch

From d85f42a91d4193df37b3861166e45aa7649bd936 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" <hjl.tools@gmail.com>
Date: Mon, 16 Sep 2024 07:11:39 +0800
Subject: [PATCH] x86/APX: Don't promote AVX512 instructions out of APX spec

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.

gas/

	PR gas/32171
	* testsuite/gas/i386/x86-64-apx-egpr-promote-inval.s: Add
	V{BROADCAST,EXTRACT,INSERT}{F,I}128 tests with EGPR.
	* testsuite/gas/i386/x86-64-apx-evex-promoted.s: Remove
	V{BROADCAST,EXTRACT,INSERT}{F,I}128 and VROUND{P,S}{S,D} tests
	with EGPR.
	* testsuite/gas/i386/x86-64-apx-egpr-inval.l: Updated.
	* testsuite/gas/i386/x86-64-apx-egpr-promote-inval.l: Likewise.
	* testsuite/gas/i386/x86-64-apx-evex-promoted-intel.d: Likewise.
	* testsuite/gas/i386/x86-64-apx-evex-promoted-wig.d: Likewise.
	* testsuite/gas/i386/x86-64-apx-evex-promoted.d: Likewise.

opcodes/

	PR gas/32171
	* i386-opc.tbl: Remove V{BROADCAST,EXTRACT,INSERT}{F,I}128 and
	VROUND{P,S}{S,D} entries with EGPR.
	* i386-tbl.h: Likewise.

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
---
 .../gas/i386/x86-64-apx-egpr-inval.l          |   8 +-
 .../gas/i386/x86-64-apx-egpr-promote-inval.l  |   6 +
 .../gas/i386/x86-64-apx-egpr-promote-inval.s  |   8 +
 .../gas/i386/x86-64-apx-evex-promoted-intel.d |  10 -
 .../gas/i386/x86-64-apx-evex-promoted-wig.d   |  10 -
 .../gas/i386/x86-64-apx-evex-promoted.d       |  10 -
 .../gas/i386/x86-64-apx-evex-promoted.s       |  10 -
 opcodes/i386-opc.tbl                          |  16 -
 opcodes/i386-tbl.h                            | 518 +++++++-----------
 9 files changed, 215 insertions(+), 381 deletions(-)

diff --git a/gas/testsuite/gas/i386/x86-64-apx-egpr-inval.l b/gas/testsuite/gas/i386/x86-64-apx-egpr-inval.l
index b018b3f7795..2525565284e 100644
--- a/gas/testsuite/gas/i386/x86-64-apx-egpr-inval.l
+++ b/gas/testsuite/gas/i386/x86-64-apx-egpr-inval.l
@@ -187,10 +187,10 @@ 
 .*:195: Error: no EVEX encoding for `vrcpps'
 .*:196: Error: no EVEX encoding for `vrcpps'
 .*:197: Error: no EVEX encoding for `vrcpss'
-.*:198: Error: .* 4 bits for `vroundpd'
-.*:199: Error: .* 4 bits for `vroundps'
-.*:200: Error: .* 4 bits for `vroundsd'
-.*:201: Error: .* 4 bits for `vroundss'
+.*:198: Error: no EVEX encoding for `vroundpd'
+.*:199: Error: no EVEX encoding for `vroundps'
+.*:200: Error: no EVEX encoding for `vroundsd'
+.*:201: Error: no EVEX encoding for `vroundss'
 .*:202: Error: no EVEX encoding for `vrsqrtps'
 .*:203: Error: no EVEX encoding for `vrsqrtps'
 .*:204: Error: no EVEX encoding for `vrsqrtss'
diff --git a/gas/testsuite/gas/i386/x86-64-apx-egpr-promote-inval.l b/gas/testsuite/gas/i386/x86-64-apx-egpr-promote-inval.l
index 6f06df91905..9c0b81860e9 100644
--- a/gas/testsuite/gas/i386/x86-64-apx-egpr-promote-inval.l
+++ b/gas/testsuite/gas/i386/x86-64-apx-egpr-promote-inval.l
@@ -20,6 +20,12 @@ 
 .*:37: Error: .*`kmovb'.*
 .*:38: Error: .*`ldtilecfg'.*
 .*:39: Error: .*`cmpexadd'.*
+.*:42: Error: no EVEX encoding for `vbroadcastf128'
+.*:43: Error: no EVEX encoding for `vbroadcasti128'
+.*:44: Error: no EVEX encoding for `vextractf128'
+.*:45: Error: no EVEX encoding for `vextracti128'
+.*:46: Error: no EVEX encoding for `vinsertf128'
+.*:47: Error: no EVEX encoding for `vinserti128'
 GAS LISTING .*
 #...
 [ 	]*1[ 	]+\# Check illegal 64bit APX EVEX promoted instructions
diff --git a/gas/testsuite/gas/i386/x86-64-apx-egpr-promote-inval.s b/gas/testsuite/gas/i386/x86-64-apx-egpr-promote-inval.s
index 5e4e08fa2fd..d23dbd3f2ca 100644
--- a/gas/testsuite/gas/i386/x86-64-apx-egpr-promote-inval.s
+++ b/gas/testsuite/gas/i386/x86-64-apx-egpr-promote-inval.s
@@ -37,3 +37,11 @@ 
 	{evex} kmovb %k1, %r8d
 	{evex} ldtilecfg (%r8)
 	{evex} cmpexadd %rax, %rcx, (%r8)
+
+	.arch default
+	vbroadcastf128	(%r16),%ymm3
+	vbroadcasti128	(%r16),%ymm3
+	vextractf128	$1,%ymm3,(%r16)
+	vextracti128	$1,%ymm3,(%r16)
+	vinsertf128	$1,(%r16),%ymm3,%ymm8
+	vinserti128	$1,(%r16),%ymm3,%ymm8
diff --git a/gas/testsuite/gas/i386/x86-64-apx-evex-promoted-intel.d b/gas/testsuite/gas/i386/x86-64-apx-evex-promoted-intel.d
index 76664548d80..54195179172 100644
--- a/gas/testsuite/gas/i386/x86-64-apx-evex-promoted-intel.d
+++ b/gas/testsuite/gas/i386/x86-64-apx-evex-promoted-intel.d
@@ -138,16 +138,6 @@  Disassembly of section \.text:
 [	 ]*[a-f0-9]+:[	 ]*62 da 7f 08 4b b4 87 23 01 00 00[	 ]+tileloadd tmm6,\[r31\+rax\*4\+0x123\]
 [	 ]*[a-f0-9]+:[	 ]*62 da 7d 08 4b b4 87 23 01 00 00[	 ]+tileloaddt1 tmm6,\[r31\+rax\*4\+0x123\]
 [	 ]*[a-f0-9]+:[	 ]*62 da 7e 08 4b b4 87 23 01 00 00[	 ]+tilestored[	 ]+\[r31\+rax\*4\+0x123\],tmm6
-[	 ]*[a-f0-9]+:[	 ]*62 fa 7d 28 1a 18[	 ]+vbroadcastf32x4 ymm3,XMMWORD PTR \[r16\]
-[	 ]*[a-f0-9]+:[	 ]*62 fa 7d 28 5a 18[	 ]+vbroadcasti32x4 ymm3,XMMWORD PTR \[r16\]
-[	 ]*[a-f0-9]+:[	 ]*62 fb 7d 28 19 18 01[	 ]+vextractf32x4 XMMWORD PTR \[r16\],ymm3,(0x)?1
-[	 ]*[a-f0-9]+:[	 ]*62 fb 7d 28 39 18 01[	 ]+vextracti32x4 XMMWORD PTR \[r16\],ymm3,(0x)?1
-[	 ]*[a-f0-9]+:[	 ]*62 7b 65 28 18 00 01[	 ]+vinsertf32x4 ymm8,ymm3,XMMWORD PTR \[r16\],(0x)?1
-[	 ]*[a-f0-9]+:[	 ]*62 7b 65 28 38 00 01[	 ]+vinserti32x4 ymm8,ymm3,XMMWORD PTR \[r16\],(0x)?1
-[	 ]*[a-f0-9]+:[	 ]*62 db fd 08 09 30 01[	 ]+vrndscalepd xmm6,XMMWORD PTR \[r24\],(0x)?1
-[	 ]*[a-f0-9]+:[	 ]*62 db 7d 08 08 30 02[	 ]+vrndscaleps xmm6,XMMWORD PTR \[r24\],(0x)?2
-[	 ]*[a-f0-9]+:[	 ]*62 db cd 08 0b 18 03[	 ]+vrndscalesd xmm3,xmm6,QWORD PTR \[r24\],(0x)?3
-[	 ]*[a-f0-9]+:[	 ]*62 db 4d 08 0a 18 04[	 ]+vrndscaless xmm3,xmm6,DWORD PTR \[r24\],(0x)?4
 [	 ]*[a-f0-9]+:[	 ]*62 4c 7c 08 66 8c 87 23 01 00 00[	 ]+wrssd[	 ]+\[r31\+rax\*4\+0x123\],r25d
 [	 ]*[a-f0-9]+:[	 ]*62 4c fc 08 66 bc 87 23 01 00 00[	 ]+wrssq[	 ]+\[r31\+rax\*4\+0x123\],r31
 [	 ]*[a-f0-9]+:[	 ]*62 4c 7d 08 65 8c 87 23 01 00 00[	 ]+wrussd[	 ]+\[r31\+rax\*4\+0x123\],r25d
diff --git a/gas/testsuite/gas/i386/x86-64-apx-evex-promoted-wig.d b/gas/testsuite/gas/i386/x86-64-apx-evex-promoted-wig.d
index e800205c0e3..bcdc43ec2a8 100644
--- a/gas/testsuite/gas/i386/x86-64-apx-evex-promoted-wig.d
+++ b/gas/testsuite/gas/i386/x86-64-apx-evex-promoted-wig.d
@@ -138,16 +138,6 @@  Disassembly of section \.text:
 [	 ]*[a-f0-9]+:[	 ]*62 da 7f 08 4b b4 87 23 01 00 00[	 ]+tileloadd[	 ]+0x123\(%r31,%rax,4\),%tmm6
 [	 ]*[a-f0-9]+:[	 ]*62 da 7d 08 4b b4 87 23 01 00 00[	 ]+tileloaddt1[	 ]+0x123\(%r31,%rax,4\),%tmm6
 [	 ]*[a-f0-9]+:[	 ]*62 da 7e 08 4b b4 87 23 01 00 00[	 ]+tilestored[	 ]+%tmm6,0x123\(%r31,%rax,4\)
-[	 ]*[a-f0-9]+:[	 ]*62 fa 7d 28 1a 18[	 ]+vbroadcastf32x4 \(%r16\),%ymm3
-[	 ]*[a-f0-9]+:[	 ]*62 fa 7d 28 5a 18[	 ]+vbroadcasti32x4 \(%r16\),%ymm3
-[	 ]*[a-f0-9]+:[	 ]*62 fb 7d 28 19 18 01[	 ]+vextractf32x4 \$(0x)?1,%ymm3,\(%r16\)
-[	 ]*[a-f0-9]+:[	 ]*62 fb 7d 28 39 18 01[	 ]+vextracti32x4 \$(0x)?1,%ymm3,\(%r16\)
-[	 ]*[a-f0-9]+:[	 ]*62 7b 65 28 18 00 01[	 ]+vinsertf32x4 \$(0x)?1,\(%r16\),%ymm3,%ymm8
-[	 ]*[a-f0-9]+:[	 ]*62 7b 65 28 38 00 01[	 ]+vinserti32x4 \$(0x)?1,\(%r16\),%ymm3,%ymm8
-[	 ]*[a-f0-9]+:[	 ]*62 db fd 08 09 30 01[	 ]+vrndscalepd \$0x1,\(%r24\),%xmm6
-[	 ]*[a-f0-9]+:[	 ]*62 db 7d 08 08 30 02[	 ]+vrndscaleps \$0x2,\(%r24\),%xmm6
-[	 ]*[a-f0-9]+:[	 ]*62 db cd 08 0b 18 03[	 ]+vrndscalesd \$0x3,\(%r24\),%xmm6,%xmm3
-[	 ]*[a-f0-9]+:[	 ]*62 db 4d 08 0a 18 04[	 ]+vrndscaless \$0x4,\(%r24\),%xmm6,%xmm3
 [	 ]*[a-f0-9]+:[	 ]*62 4c 7c 08 66 8c 87 23 01 00 00[	 ]+wrssd[	 ]+%r25d,0x123\(%r31,%rax,4\)
 [	 ]*[a-f0-9]+:[	 ]*62 4c fc 08 66 bc 87 23 01 00 00[	 ]+wrssq[	 ]+%r31,0x123\(%r31,%rax,4\)
 [	 ]*[a-f0-9]+:[	 ]*62 4c 7d 08 65 8c 87 23 01 00 00[	 ]+wrussd[	 ]+%r25d,0x123\(%r31,%rax,4\)
diff --git a/gas/testsuite/gas/i386/x86-64-apx-evex-promoted.d b/gas/testsuite/gas/i386/x86-64-apx-evex-promoted.d
index a8f9231b5b0..c72f7012c0e 100644
--- a/gas/testsuite/gas/i386/x86-64-apx-evex-promoted.d
+++ b/gas/testsuite/gas/i386/x86-64-apx-evex-promoted.d
@@ -138,16 +138,6 @@  Disassembly of section \.text:
 [	 ]*[a-f0-9]+:[	 ]*62 da 7f 08 4b b4 87 23 01 00 00[	 ]+tileloadd[	 ]+0x123\(%r31,%rax,4\),%tmm6
 [	 ]*[a-f0-9]+:[	 ]*62 da 7d 08 4b b4 87 23 01 00 00[	 ]+tileloaddt1[	 ]+0x123\(%r31,%rax,4\),%tmm6
 [	 ]*[a-f0-9]+:[	 ]*62 da 7e 08 4b b4 87 23 01 00 00[	 ]+tilestored[	 ]+%tmm6,0x123\(%r31,%rax,4\)
-[	 ]*[a-f0-9]+:[	 ]*62 fa 7d 28 1a 18[	 ]+vbroadcastf32x4 \(%r16\),%ymm3
-[	 ]*[a-f0-9]+:[	 ]*62 fa 7d 28 5a 18[	 ]+vbroadcasti32x4 \(%r16\),%ymm3
-[	 ]*[a-f0-9]+:[	 ]*62 fb 7d 28 19 18 01[	 ]+vextractf32x4 \$(0x)?1,%ymm3,\(%r16\)
-[	 ]*[a-f0-9]+:[	 ]*62 fb 7d 28 39 18 01[	 ]+vextracti32x4 \$(0x)?1,%ymm3,\(%r16\)
-[	 ]*[a-f0-9]+:[	 ]*62 7b 65 28 18 00 01[	 ]+vinsertf32x4 \$(0x)?1,\(%r16\),%ymm3,%ymm8
-[	 ]*[a-f0-9]+:[	 ]*62 7b 65 28 38 00 01[	 ]+vinserti32x4 \$(0x)?1,\(%r16\),%ymm3,%ymm8
-[	 ]*[a-f0-9]+:[	 ]*62 db fd 08 09 30 01[	 ]+vrndscalepd \$0x1,\(%r24\),%xmm6
-[	 ]*[a-f0-9]+:[	 ]*62 db 7d 08 08 30 02[	 ]+vrndscaleps \$0x2,\(%r24\),%xmm6
-[	 ]*[a-f0-9]+:[	 ]*62 db cd 08 0b 18 03[	 ]+vrndscalesd \$0x3,\(%r24\),%xmm6,%xmm3
-[	 ]*[a-f0-9]+:[	 ]*62 db 4d 08 0a 18 04[	 ]+vrndscaless \$0x4,\(%r24\),%xmm6,%xmm3
 [	 ]*[a-f0-9]+:[	 ]*62 4c 7c 08 66 8c 87 23 01 00 00[	 ]+wrssd[	 ]+%r25d,0x123\(%r31,%rax,4\)
 [	 ]*[a-f0-9]+:[	 ]*62 4c fc 08 66 bc 87 23 01 00 00[	 ]+wrssq[	 ]+%r31,0x123\(%r31,%rax,4\)
 [	 ]*[a-f0-9]+:[	 ]*62 4c 7d 08 65 8c 87 23 01 00 00[	 ]+wrussd[	 ]+%r25d,0x123\(%r31,%rax,4\)
diff --git a/gas/testsuite/gas/i386/x86-64-apx-evex-promoted.s b/gas/testsuite/gas/i386/x86-64-apx-evex-promoted.s
index 1ba7d72cf9e..b66ee19df69 100644
--- a/gas/testsuite/gas/i386/x86-64-apx-evex-promoted.s
+++ b/gas/testsuite/gas/i386/x86-64-apx-evex-promoted.s
@@ -132,16 +132,6 @@  _start:
 	tileloadd	0x123(%r31,%rax,4),%tmm6
 	tileloaddt1	0x123(%r31,%rax,4),%tmm6
 	tilestored	%tmm6,0x123(%r31,%rax,4)
-	vbroadcastf128	(%r16),%ymm3
-	vbroadcasti128	(%r16),%ymm3
-	vextractf128	$1,%ymm3,(%r16)
-	vextracti128	$1,%ymm3,(%r16)
-	vinsertf128	$1,(%r16),%ymm3,%ymm8
-	vinserti128	$1,(%r16),%ymm3,%ymm8
-	vroundpd $1,(%r24),%xmm6
-	vroundps $2,(%r24),%xmm6
-	vroundsd $3,(%r24),%xmm6,%xmm3
-	vroundss $4,(%r24),%xmm6,%xmm3
 	wrssd	%r25d,0x123(%r31,%rax,4)
 	wrssq	%r31,0x123(%r31,%rax,4)
 	wrussd	%r25d,0x123(%r31,%rax,4)
diff --git a/opcodes/i386-opc.tbl b/opcodes/i386-opc.tbl
index 5049a3b00f2..350c5a8cdb2 100644
--- a/opcodes/i386-opc.tbl
+++ b/opcodes/i386-opc.tbl
@@ -1663,8 +1663,6 @@  vandp<sd>, 0x<sd:ppfx>54, AVX, Modrm|C|Vex|Space0F|Src1VVVV|VexWIG|CheckOperandS
 vblendp<sd>, 0x660c | <sd:opc>, AVX, Modrm|Vex|Space0F3A|Src1VVVV|VexWIG|CheckOperandSize|NoSuf, { Imm8|Imm8S, Unspecified|BaseIndex|RegXMM|RegYMM, RegXMM|RegYMM, RegXMM|RegYMM }
 vblendvp<sd>, 0x664a | <sd:opc>, AVX, Modrm|Vex|Space0F3A|Src1VVVV|VexW0|CheckOperandSize|NoSuf, { RegXMM|RegYMM, Unspecified|BaseIndex|RegXMM|RegYMM, RegXMM|RegYMM, RegXMM|RegYMM }
 vbroadcastf128, 0x661a, AVX, Modrm|Vex256|Space0F38|VexW0|NoSuf, { Xmmword|Unspecified|BaseIndex, RegYMM }
-// vbroadcastf32x4 in disguise (see vround{p,s}{s,d} comment)
-vbroadcastf128, 0x661a, APX_F&AVX512VL, Modrm|EVex256|Space0F38|VexW0|Disp8MemShift=4|NoSuf, { Xmmword|Unspecified|BaseIndex, RegYMM }
 vbroadcastsd, 0x6619, AVX, Modrm|Vex256|Space0F38|VexW0|NoSuf, { Qword|Unspecified|BaseIndex, RegYMM }
 vbroadcastss, 0x6618, AVX, Modrm|Vex128|Space0F38|VexW0|NoSuf, { Dword|Unspecified|BaseIndex, RegXMM|RegYMM }
 vcmp<frel>p<sd>, 0x<sd:ppfx>c2/0x<frel:imm>, AVX, Modrm|<frel:comm>|Vex|Space0F|Src1VVVV|VexWIG|CheckOperandSize|NoSuf|ImmExt, { RegXMM|RegYMM|Unspecified|BaseIndex, RegXMM|RegYMM, RegXMM|RegYMM }
@@ -1693,8 +1691,6 @@  vdivs<sd>, 0x<sd:spfx>5e, AVX, Modrm|VexLIG|Space0F|Src1VVVV|VexWIG|NoSuf, { <sd
 vdppd, 0x6641, AVX, Modrm|Vex|Space0F3A|Src1VVVV|VexWIG|NoSuf, { Imm8|Imm8S, Unspecified|BaseIndex|RegXMM, RegXMM, RegXMM }
 vdpps, 0x6640, AVX, Modrm|Vex|Space0F3A|Src1VVVV|VexWIG|CheckOperandSize|NoSuf, { Imm8|Imm8S, Unspecified|BaseIndex|RegXMM|RegYMM, RegXMM|RegYMM, RegXMM|RegYMM }
 vextractf128, 0x6619, AVX, Modrm|Vex256|Space0F3A|VexW0|NoSuf, { Imm8, RegYMM, Unspecified|BaseIndex|RegXMM }
-// vextractf32x4 in disguise (see vround{p,s}{s,d} comment)
-vextractf128, 0x6619, APX_F&AVX512VL, Modrm|EVex256|Space0F3A|VexW0|Disp8MemShift=4|NoSuf, { Imm8, RegYMM, Xmmword|Unspecified|BaseIndex }
 vextractps, 0x6617, AVX|AVX512F, Modrm|Vex128|EVex128|Space0F3A|VexWIG|Disp8MemShift=2|NoSuf, { Imm8, RegXMM, Reg32|Unspecified|BaseIndex }
 vextractps, 0x6617, x64&(AVX|AVX512F), RegMem|Vex128|EVex128|Space0F3A|VexWIG|NoSuf, { Imm8, RegXMM, Reg64 }
 vhaddpd, 0x667c, AVX, Modrm|Vex|Space0F|Src1VVVV|VexWIG|CheckOperandSize|NoSuf, { Unspecified|BaseIndex|RegXMM|RegYMM, RegXMM|RegYMM, RegXMM|RegYMM }
@@ -1702,8 +1698,6 @@  vhaddps, 0xf27c, AVX, Modrm|Vex|Space0F|Src1VVVV|VexWIG|CheckOperandSize|NoSuf,
 vhsubpd, 0x667d, AVX, Modrm|Vex|Space0F|Src1VVVV|VexWIG|CheckOperandSize|NoSuf, { Unspecified|BaseIndex|RegXMM|RegYMM, RegXMM|RegYMM, RegXMM|RegYMM }
 vhsubps, 0xf27d, AVX, Modrm|Vex|Space0F|Src1VVVV|VexWIG|CheckOperandSize|NoSuf, { Unspecified|BaseIndex|RegXMM|RegYMM, RegXMM|RegYMM, RegXMM|RegYMM }
 vinsertf128, 0x6618, AVX, Modrm|Vex256|Space0F3A|Src1VVVV|VexW0|NoSuf, { Imm8, Unspecified|BaseIndex|RegXMM, RegYMM, RegYMM }
-// vinsertf32x4 in disguise (see vround{p,s}{s,d} comment)
-vinsertf128, 0x6618, APX_F&AVX512VL, Modrm|EVex256|Space0F3A|Src1VVVV|VexW0|Disp8MemShift=4|NoSuf, { Imm8, Xmmword|Unspecified|BaseIndex, RegYMM, RegYMM }
 vinsertps, 0x6621, AVX, Modrm|Vex|Space0F3A|Src1VVVV|VexWIG|NoSuf, { Imm8, Dword|Unspecified|BaseIndex|RegXMM, RegXMM, RegXMM }
 vlddqu, 0xf2f0, AVX, Modrm|Vex|Space0F|VexWIG|CheckOperandSize|NoSuf, { Xmmword|Ymmword|Unspecified|BaseIndex, RegXMM|RegYMM }
 vldmxcsr, 0xae/2, AVX, Modrm|Vex128|Space0F|VexWIG|NoSuf, { Dword|Unspecified|BaseIndex }
@@ -1872,10 +1866,6 @@  vrcpps, 0x53, AVX, Modrm|Vex|Space0F|VexWIG|CheckOperandSize|NoSuf, { Unspecifie
 vrcpss, 0xf353, AVX, Modrm|Vex=3|Space0F|Src1VVVV|VexWIG|NoSuf, { Dword|Unspecified|BaseIndex|RegXMM, RegXMM, RegXMM }
 vroundp<sd>, 0x6608 | <sd:opc>, AVX, Modrm|Vex|Space0F3A|VexWIG|CheckOperandSize|NoSuf, { Imm8, Unspecified|BaseIndex|RegXMM|RegYMM, RegXMM|RegYMM }
 vrounds<sd>, 0x660a | <sd:opc>, AVX, Modrm|VexLIG|Space0F3A|Src1VVVV|VexWIG|NoSuf, { Imm8, <sd:elem>|Unspecified|BaseIndex|RegXMM, RegXMM, RegXMM }
-// These are really clones of VRNDSCALE{P,S}{S,D}, with broadcast, masking, SAE,
-// 512-bit operand size, and register sources dropped.
-vroundp<sd>, 0x6608 | <sd:opc>, APX_F&AVX512VL, Modrm|Space0F3A|<sd:vexw>|Disp8ShiftVL|CheckOperandSize|NoSuf, { Imm8, Xmmword|Ymmword|Unspecified|BaseIndex, RegXMM|RegYMM }
-vrounds<sd>, 0x660a | <sd:opc>, APX_F&AVX512F, Modrm|EVexLIG|Space0F3A|Src1VVVV|<sd:vexw>|Disp8MemShift|NoSuf, { Imm8, <sd:elem>|Unspecified|BaseIndex, RegXMM, RegXMM }
 vrsqrtps, 0x52, AVX, Modrm|Vex|Space0F|VexWIG|CheckOperandSize|NoSuf, { Unspecified|BaseIndex|RegXMM|RegYMM, RegXMM|RegYMM }
 vrsqrtss, 0xf352, AVX, Modrm|Vex=3|Space0F|Src1VVVV|VexWIG|NoSuf, { Dword|Unspecified|BaseIndex|RegXMM, RegXMM, RegXMM }
 vshufp<sd>, 0x<sd:ppfx>c6, AVX, Modrm|Vex|Space0F|Src1VVVV|VexWIG|CheckOperandSize|NoSuf, { Imm8|Imm8S, Unspecified|BaseIndex|RegXMM|RegYMM, RegXMM|RegYMM, RegXMM|RegYMM }
@@ -1911,8 +1901,6 @@  vpmovzxwq, 0x6634, AVX2|AVX512VL, Modrm|Vex256|EVex256|Masking|Space0F38|VexWIG|
 // New AVX2 instructions.
 
 vbroadcasti128, 0x665A, AVX2, Modrm|Vex256|Space0F38|VexW0|NoSuf, { Xmmword|Unspecified|BaseIndex, RegYMM }
-// vbroadcasti32x4 in disguise (see vround{p,s}{s,d} comment)
-vbroadcasti128, 0x665a, APX_F&AVX512VL, Modrm|EVex256|Space0F38|VexW0|Disp8MemShift=4|NoSuf, { Xmmword|Unspecified|BaseIndex, RegYMM }
 vbroadcastsd, 0x6619, AVX2, Modrm|Vex=2|Space0F38|VexW=1|NoSuf, { RegXMM, RegYMM }
 vbroadcastss, 0x6618, AVX2|AVX512F, Modrm|Vex|EVexDYN|Masking|Space0F38|VexW0|Disp8MemShift=2|NoSuf, { RegXMM|Dword|Unspecified|BaseIndex, RegXMM|RegYMM|RegZMM }
 vpblendd, 0x6602, AVX2, Modrm|Vex|Space0F3A|Src1VVVV|VexW0|CheckOperandSize|NoSuf, { Imm8|Imm8S, Unspecified|BaseIndex|RegXMM|RegYMM, RegXMM|RegYMM, RegXMM|RegYMM }
@@ -1925,11 +1913,7 @@  vpermpd, 0x6601, AVX2|AVX512F, Modrm|Vex256|EVexDYN|Masking|Space0F3A|VexW1|Broa
 vpermps, 0x6616, AVX2|AVX512F, Modrm|Vex256|EVexDYN|Masking|Space0F38|Src1VVVV|VexW0|Broadcast|Disp8ShiftVL|CheckOperandSize|NoSuf, { RegYMM|RegZMM|Dword|Unspecified|BaseIndex, RegYMM|RegZMM, RegYMM|RegZMM }
 vpermq, 0x6600, AVX2|AVX512F, Modrm|Vex256|EVexDYN|Masking|Space0F3A|VexW1|Broadcast|Disp8ShiftVL|CheckOperandSize|NoSuf, { Imm8|Imm8S, RegYMM|RegZMM|Qword|Unspecified|BaseIndex, RegYMM|RegZMM }
 vextracti128, 0x6639, AVX2, Modrm|Vex256|Space0F3A|VexW0|NoSuf, { Imm8, RegYMM, Unspecified|BaseIndex|RegXMM }
-// vextracti32x4 in disguise (see vround{p,s}{s,d} comment)
-vextracti128, 0x6639, APX_F&AVX512VL, Modrm|EVex256|Space0F3A|VexW0|Disp8MemShift=4|NoSuf, { Imm8, RegYMM, Xmmword|Unspecified|BaseIndex }
 vinserti128, 0x6638, AVX2, Modrm|Vex256|Space0F3A|Src1VVVV|VexW0|NoSuf, { Imm8, Unspecified|BaseIndex|RegXMM, RegYMM, RegYMM }
-// vinserti32x4 in disguise (see vround{p,s}{s,d} comment)
-vinserti128, 0x6638, APX_F&AVX512VL, Modrm|EVex256|Space0F3A|Src1VVVV|VexW0|Disp8MemShift=4|NoSuf, { Imm8, Xmmword|Unspecified|BaseIndex, RegYMM, RegYMM }
 vpmaskmov<dq>, 0x668e, AVX2, Modrm|Vex|Space0F38|Src1VVVV|<dq:vexw>|CheckOperandSize|NoSuf, { RegXMM|RegYMM, RegXMM|RegYMM, Xmmword|Ymmword|Unspecified|BaseIndex }
 vpmaskmov<dq>, 0x668c, AVX2, Modrm|Vex|Space0F38|Src1VVVV|<dq:vexw>|CheckOperandSize|NoSuf, { Xmmword|Ymmword|Unspecified|BaseIndex, RegXMM|RegYMM, RegXMM|RegYMM }
 vpsllv<dq>, 0x6647, AVX2|AVX512F, Modrm|Vex|EVexDYN|Masking|Space0F38|Src1VVVV|<dq:vexw>|Broadcast|Disp8ShiftVL|CheckOperandSize|NoSuf, { RegXMM|RegYMM|RegZMM|<dq:elem>|Unspecified|BaseIndex, RegXMM|RegYMM|RegZMM, RegXMM|RegYMM|RegZMM }
diff --git a/opcodes/i386-tbl.h b/opcodes/i386-tbl.h
index 631e2a62bfc..9f234669dc5 100644
--- a/opcodes/i386-tbl.h
+++ b/opcodes/i386-tbl.h
@@ -20050,16 +20050,6 @@  static const insn_template i386_optab[] =
 	  1, 0, 0, 0, 1, 0 } },
       { { 7, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
 	  0, 1, 0, 0, 0, 0 } } } },
-  { MN_vbroadcastf128, 0x1a, 2, SPACE_0F38, None,
-    { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0,
-      0, 0, 0, 0, 0, 1, 1, 0, 0, 3, 0, 0, 0, 0, 4, 0, 0, 0, 0, 0,
-      0, 0 },
-    { { 0, 0, 0, 0, 0, 1, 0, 0, 0, 1, 1, 0, 0 } },
-    { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } },
-    { { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 1, 0, 0, 0, 0, 0, 0,
-	  1, 0, 0, 0, 1, 0 } },
-      { { 7, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-	  0, 1, 0, 0, 0, 0 } } } },
   { MN_vbroadcastsd, 0x19, 2, SPACE_0F38, None,
     { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0,
       0, 0, 0, 2, 0, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1,
@@ -25492,18 +25482,6 @@  static const insn_template i386_optab[] =
 	  0, 1, 0, 0, 0, 0 } },
       { { 7, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, 1, 0, 0, 0, 0, 0, 0,
 	  1, 0, 0, 0, 1, 0 } } } },
-  { MN_vextractf128, 0x19, 3, SPACE_0F3A, None,
-    { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0,
-      0, 0, 0, 0, 0, 1, 1, 0, 0, 3, 0, 0, 0, 0, 4, 0, 0, 0, 0, 0,
-      0, 0 },
-    { { 0, 0, 0, 0, 0, 1, 0, 0, 0, 1, 1, 0, 0 } },
-    { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } },
-    { { { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-	  0, 0, 0, 0, 0, 0 } },
-      { { 7, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-	  0, 1, 0, 0, 0, 0 } },
-      { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 1, 0, 0, 0, 0, 0, 0,
-	  1, 0, 0, 0, 1, 0 } } } },
   { MN_vextractps, 0x17, 3, SPACE_0F3A, None,
     { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0,
       0, 0, 0, 1, 0, 3, 1, 0, 0, 2, 0, 0, 0, 0, 2, 0, 0, 0, 0, 0,
@@ -25590,20 +25568,6 @@  static const insn_template i386_optab[] =
 	  0, 1, 0, 0, 0, 0 } },
       { { 7, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
 	  0, 1, 0, 0, 0, 0 } } } },
-  { MN_vinsertf128, 0x18, 4, SPACE_0F3A, None,
-    { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0,
-      0, 0, 0, 0, 1, 1, 1, 0, 0, 3, 0, 0, 0, 0, 4, 0, 0, 0, 0, 0,
-      0, 0 },
-    { { 0, 0, 0, 0, 0, 1, 0, 0, 0, 1, 1, 0, 0 } },
-    { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } },
-    { { { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-	  0, 0, 0, 0, 0, 0 } },
-      { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 1, 0, 0, 0, 0, 0, 0,
-	  1, 0, 0, 0, 1, 0 } },
-      { { 7, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-	  0, 1, 0, 0, 0, 0 } },
-      { { 7, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-	  0, 1, 0, 0, 0, 0 } } } },
   { MN_vinsertps, 0x21, 4, SPACE_0F3A, None,
     { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0,
       0, 0, 0, 1, 1, 3, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1,
@@ -30006,18 +29970,6 @@  static const insn_template i386_optab[] =
 	  1, 1, 0, 0, 1, 0 } },
       { { 7, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
 	  1, 1, 0, 0, 0, 0 } } } },
-  { MN_vroundps, 0x08 | 0, 3, SPACE_0F3A, None,
-    { 0, 0, 0, 1, 0, 0, 0, 1, 0, 0, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0,
-      0, 0, 0, 0, 0, 1, 1, 0, 0, 5, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0,
-      0, 0 },
-    { { 0, 0, 0, 0, 0, 1, 0, 0, 0, 1, 1, 0, 0 } },
-    { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } },
-    { { { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-	  0, 0, 0, 0, 0, 0 } },
-      { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 1, 0, 0, 0, 0, 0, 0,
-	  1, 1, 0, 0, 1, 0 } },
-      { { 7, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-	  1, 1, 0, 0, 0, 0 } } } },
   { MN_vroundpd, 0x08 | 1, 3, SPACE_0F3A, None,
     { 0, 0, 0, 1, 0, 0, 0, 1, 0, 0, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0,
       0, 0, 0, 1, 0, 3, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1,
@@ -30030,18 +29982,6 @@  static const insn_template i386_optab[] =
 	  1, 1, 0, 0, 1, 0 } },
       { { 7, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
 	  1, 1, 0, 0, 0, 0 } } } },
-  { MN_vroundpd, 0x08 | 1, 3, SPACE_0F3A, None,
-    { 0, 0, 0, 1, 0, 0, 0, 1, 0, 0, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0,
-      0, 0, 0, 0, 0, 2, 1, 0, 0, 5, 0, 0, 0, 0, 7, 0, 0, 0, 0, 0,
-      0, 0 },
-    { { 0, 0, 0, 0, 0, 1, 0, 0, 0, 1, 1, 0, 0 } },
-    { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } },
-    { { { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-	  0, 0, 0, 0, 0, 0 } },
-      { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 1, 0, 0, 0, 0, 0, 0,
-	  1, 1, 0, 0, 1, 0 } },
-      { { 7, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-	  1, 1, 0, 0, 0, 0 } } } },
   { MN_vroundss, 0x0a | 0, 4, SPACE_0F3A, None,
     { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0,
       0, 0, 0, 3, 1, 3, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1,
@@ -30056,20 +29996,6 @@  static const insn_template i386_optab[] =
 	  1, 0, 0, 0, 0, 0 } },
       { { 7, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
 	  1, 0, 0, 0, 0, 0 } } } },
-  { MN_vroundss, 0x0a | 0, 4, SPACE_0F3A, None,
-    { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0,
-      0, 0, 0, 0, 1, 1, 1, 0, 0, 4, 0, 0, 0, 0, 2, 0, 0, 0, 0, 0,
-      0, 0 },
-    { { 0, 0, 0, 0, 0, 1, 0, 0, 1, 0, 1, 0, 0 } },
-    { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } },
-    { { { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-	  0, 0, 0, 0, 0, 0 } },
-      { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 1, 0, 0, 1, 0, 0, 0,
-	  0, 0, 0, 0, 1, 0 } },
-      { { 7, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-	  1, 0, 0, 0, 0, 0 } },
-      { { 7, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-	  1, 0, 0, 0, 0, 0 } } } },
   { MN_vroundsd, 0x0a | 1, 4, SPACE_0F3A, None,
     { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0,
       0, 0, 0, 3, 1, 3, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1,
@@ -30084,20 +30010,6 @@  static const insn_template i386_optab[] =
 	  1, 0, 0, 0, 0, 0 } },
       { { 7, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
 	  1, 0, 0, 0, 0, 0 } } } },
-  { MN_vroundsd, 0x0a | 1, 4, SPACE_0F3A, None,
-    { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0,
-      0, 0, 0, 0, 1, 2, 1, 0, 0, 4, 0, 0, 0, 0, 3, 0, 0, 0, 0, 0,
-      0, 0 },
-    { { 0, 0, 0, 0, 0, 1, 0, 0, 1, 0, 1, 0, 0 } },
-    { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } },
-    { { { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-	  0, 0, 0, 0, 0, 0 } },
-      { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 1, 0, 0, 0, 0, 1, 0,
-	  0, 0, 0, 0, 1, 0 } },
-      { { 7, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-	  1, 0, 0, 0, 0, 0 } },
-      { { 7, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-	  1, 0, 0, 0, 0, 0 } } } },
   { MN_vrsqrtps, 0x52, 2, SPACE_0F, None,
     { 0, 0, 0, 1, 0, 0, 0, 1, 0, 0, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0,
       0, 0, 0, 1, 0, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1,
@@ -30598,16 +30510,6 @@  static const insn_template i386_optab[] =
 	  1, 0, 0, 0, 1, 0 } },
       { { 7, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
 	  0, 1, 0, 0, 0, 0 } } } },
-  { MN_vbroadcasti128, 0x5a, 2, SPACE_0F38, None,
-    { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0,
-      0, 0, 0, 0, 0, 1, 1, 0, 0, 3, 0, 0, 0, 0, 4, 0, 0, 0, 0, 0,
-      0, 0 },
-    { { 0, 0, 0, 0, 0, 1, 0, 0, 0, 1, 1, 0, 0 } },
-    { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } },
-    { { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 1, 0, 0, 0, 0, 0, 0,
-	  1, 0, 0, 0, 1, 0 } },
-      { { 7, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-	  0, 1, 0, 0, 0, 0 } } } },
   { MN_vpblendd, 0x02, 4, SPACE_0F3A, None,
     { 0, 0, 0, 1, 0, 0, 0, 1, 0, 0, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0,
       0, 0, 0, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1,
@@ -30830,18 +30732,6 @@  static const insn_template i386_optab[] =
 	  0, 1, 0, 0, 0, 0 } },
       { { 7, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 0, 1, 0, 0, 0, 0, 0, 0,
 	  1, 0, 0, 0, 1, 0 } } } },
-  { MN_vextracti128, 0x39, 3, SPACE_0F3A, None,
-    { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0,
-      0, 0, 0, 0, 0, 1, 1, 0, 0, 3, 0, 0, 0, 0, 4, 0, 0, 0, 0, 0,
-      0, 0 },
-    { { 0, 0, 0, 0, 0, 1, 0, 0, 0, 1, 1, 0, 0 } },
-    { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } },
-    { { { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-	  0, 0, 0, 0, 0, 0 } },
-      { { 7, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-	  0, 1, 0, 0, 0, 0 } },
-      { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 1, 0, 0, 0, 0, 0, 0,
-	  1, 0, 0, 0, 1, 0 } } } },
   { MN_vinserti128, 0x38, 4, SPACE_0F3A, None,
     { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0,
       0, 0, 0, 2, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1,
@@ -30856,20 +30746,6 @@  static const insn_template i386_optab[] =
 	  0, 1, 0, 0, 0, 0 } },
       { { 7, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
 	  0, 1, 0, 0, 0, 0 } } } },
-  { MN_vinserti128, 0x38, 4, SPACE_0F3A, None,
-    { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0,
-      0, 0, 0, 0, 1, 1, 1, 0, 0, 3, 0, 0, 0, 0, 4, 0, 0, 0, 0, 0,
-      0, 0 },
-    { { 0, 0, 0, 0, 0, 1, 0, 0, 0, 1, 1, 0, 0 } },
-    { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 } },
-    { { { 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-	  0, 0, 0, 0, 0, 0 } },
-      { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 1, 0, 1, 0, 0, 0, 0, 0, 0,
-	  1, 0, 0, 0, 1, 0 } },
-      { { 7, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-	  0, 1, 0, 0, 0, 0 } },
-      { { 7, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
-	  0, 1, 0, 0, 0, 0 } } } },
   { MN_vpmaskmovd, 0x8e, 3, SPACE_0F38, None,
     { 0, 0, 0, 1, 0, 0, 0, 1, 0, 0, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0,
       0, 0, 0, 1, 1, 1, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1,
@@ -46017,203 +45893,203 @@  static const i386_op_off_t i386_op_sets[] =
   2019, 2021, 2023, 2025, 2027, 2029, 2031, 2033,
   2035, 2037, 2039, 2041, 2043, 2045, 2047, 2049,
   2051, 2053, 2055, 2056, 2057, 2059, 2061, 2063,
-  2065, 2066, 2067, 2068, 2069, 2071, 2074, 2076,
-  2078, 2080, 2082, 2084, 2086, 2088, 2090, 2092,
-  2094, 2096, 2098, 2100, 2102, 2104, 2106, 2108,
-  2110, 2112, 2114, 2116, 2118, 2120, 2122, 2124,
-  2126, 2128, 2130, 2132, 2134, 2136, 2138, 2140,
-  2142, 2144, 2146, 2148, 2150, 2152, 2154, 2156,
-  2158, 2160, 2162, 2164, 2166, 2168, 2170, 2172,
-  2174, 2176, 2178, 2180, 2182, 2184, 2186, 2188,
-  2190, 2192, 2194, 2196, 2198, 2200, 2202, 2204,
-  2206, 2208, 2210, 2212, 2214, 2216, 2218, 2220,
-  2222, 2224, 2226, 2228, 2230, 2232, 2234, 2236,
-  2238, 2240, 2242, 2244, 2246, 2248, 2250, 2252,
-  2254, 2256, 2258, 2260, 2262, 2264, 2266, 2268,
-  2270, 2272, 2274, 2276, 2278, 2280, 2282, 2284,
-  2286, 2288, 2290, 2292, 2294, 2296, 2298, 2300,
-  2302, 2304, 2306, 2308, 2310, 2312, 2314, 2316,
-  2318, 2320, 2322, 2324, 2326, 2328, 2330, 2332,
-  2334, 2336, 2338, 2340, 2342, 2344, 2346, 2348,
-  2350, 2352, 2354, 2356, 2358, 2360, 2362, 2364,
-  2366, 2368, 2370, 2372, 2374, 2376, 2378, 2380,
-  2382, 2384, 2386, 2388, 2390, 2392, 2394, 2396,
-  2398, 2400, 2402, 2404, 2406, 2408, 2410, 2412,
-  2414, 2416, 2418, 2420, 2422, 2424, 2426, 2428,
-  2430, 2432, 2434, 2436, 2438, 2440, 2442, 2444,
-  2446, 2448, 2450, 2452, 2454, 2456, 2461, 2463,
-  2468, 2470, 2472, 2477, 2479, 2481, 2483, 2488,
-  2490, 2492, 2494, 2498, 2504, 2506, 2511, 2513,
-  2515, 2517, 2519, 2521, 2523, 2525, 2527, 2529,
-  2530, 2531, 2533, 2535, 2536, 2537, 2538, 2539,
-  2541, 2543, 2544, 2545, 2546, 2548, 2550, 2552,
-  2554, 2556, 2558, 2560, 2562, 2564, 2566, 2568,
-  2570, 2572, 2576, 2577, 2578, 2580, 2584, 2588,
-  2590, 2594, 2598, 2599, 2600, 2602, 2604, 2606,
-  2608, 2613, 2617, 2621, 2623, 2625, 2627, 2629,
-  2630, 2632, 2634, 2636, 2638, 2640, 2642, 2644,
-  2646, 2648, 2650, 2652, 2654, 2656, 2658, 2660,
-  2662, 2664, 2666, 2668, 2670, 2672, 2674, 2675,
-  2676, 2678, 2680, 2681, 2682, 2685, 2688, 2691,
-  2694, 2696, 2698, 2700, 2702, 2704, 2706, 2707,
-  2708, 2709, 2711, 2715, 2717, 2719, 2725, 2729,
-  2730, 2731, 2732, 2733, 2734, 2735, 2736, 2740,
-  2742, 2744, 2748, 2750, 2752, 2754, 2756, 2758,
-  2760, 2762, 2764, 2766, 2768, 2770, 2772, 2774,
-  2776, 2777, 2780, 2783, 2788, 2793, 2796, 2799,
-  2802, 2805, 2810, 2815, 2818, 2821, 2823, 2825,
-  2827, 2829, 2831, 2833, 2835, 2836, 2838, 2840,
-  2842, 2844, 2846, 2847, 2848, 2849, 2853, 2857,
-  2859, 2863, 2867, 2871, 2875, 2879, 2881, 2885,
-  2887, 2889, 2891, 2893, 2895, 2897, 2899, 2901,
-  2902, 2904, 2906, 2908, 2910, 2912, 2914, 2916,
-  2918, 2919, 2920, 2921, 2923, 2925, 2927, 2929,
-  2930, 2931, 2933, 2935, 2937, 2939, 2941, 2943,
-  2944, 2946, 2948, 2950, 2952, 2953, 2954, 2956,
-  2958, 2960, 2962, 2964, 2966, 2968, 2970, 2971,
-  2972, 2974, 2975, 2978, 2981, 2983, 2986, 2987,
-  2988, 2990, 2991, 2993, 2995, 2997, 2999, 3001,
-  3002, 3003, 3004, 3005, 3006, 3009, 3014, 3019,
-  3024, 3029, 3032, 3037, 3042, 3044, 3046, 3048,
-  3050, 3051, 3052, 3054, 3056, 3058, 3060, 3062,
-  3064, 3066, 3067, 3068, 3069, 3070, 3071, 3072,
-  3077, 3082, 3083, 3084, 3085, 3086, 3087, 3088,
-  3089, 3090, 3091, 3092, 3093, 3094, 3095, 3096,
-  3097, 3098, 3099, 3100, 3101, 3102, 3103, 3104,
-  3105, 3106, 3107, 3108, 3109, 3110, 3111, 3112,
-  3113, 3114, 3115, 3116, 3117, 3118, 3119, 3120,
-  3121, 3122, 3123, 3124, 3125, 3126, 3127, 3128,
-  3129, 3130, 3131, 3132, 3133, 3134, 3135, 3136,
-  3137, 3138, 3139, 3140, 3141, 3142, 3143, 3144,
-  3145, 3146, 3147, 3148, 3149, 3150, 3151, 3152,
-  3153, 3154, 3155, 3156, 3157, 3158, 3159, 3160,
-  3161, 3162, 3163, 3164, 3165, 3166, 3167, 3168,
-  3169, 3170, 3171, 3172, 3173, 3174, 3175, 3176,
-  3177, 3178, 3179, 3180, 3181, 3182, 3183, 3184,
-  3185, 3186, 3187, 3188, 3189, 3190, 3191, 3192,
-  3193, 3194, 3195, 3196, 3197, 3198, 3199, 3200,
-  3201, 3202, 3203, 3204, 3205, 3206, 3207, 3208,
-  3209, 3210, 3211, 3212, 3213, 3214, 3215, 3216,
-  3217, 3218, 3219, 3220, 3221, 3222, 3223, 3224,
-  3225, 3226, 3227, 3228, 3229, 3230, 3231, 3232,
-  3233, 3234, 3235, 3236, 3237, 3238, 3239, 3240,
-  3241, 3242, 3243, 3244, 3245, 3246, 3247, 3248,
-  3249, 3250, 3251, 3252, 3253, 3254, 3255, 3256,
-  3257, 3258, 3259, 3260, 3261, 3262, 3263, 3264,
-  3265, 3266, 3267, 3268, 3269, 3270, 3271, 3272,
-  3273, 3274, 3275, 3276, 3277, 3278, 3279, 3280,
-  3281, 3282, 3283, 3285, 3287, 3288, 3289, 3290,
-  3291, 3292, 3293, 3294, 3295, 3296, 3297, 3298,
-  3299, 3300, 3301, 3302, 3303, 3304, 3305, 3306,
-  3307, 3308, 3309, 3310, 3311, 3312, 3313, 3314,
-  3315, 3317, 3319, 3321, 3323, 3324, 3325, 3326,
-  3327, 3328, 3329, 3330, 3331, 3332, 3333, 3334,
-  3335, 3336, 3338, 3339, 3340, 3341, 3343, 3344,
-  3345, 3346, 3347, 3348, 3349, 3350, 3351, 3352,
-  3353, 3354, 3355, 3356, 3357, 3358, 3359, 3360,
-  3361, 3362, 3363, 3364, 3365, 3366, 3367, 3368,
-  3369, 3370, 3371, 3372, 3373, 3374, 3375, 3376,
-  3377, 3378, 3379, 3380, 3381, 3382, 3383, 3384,
-  3386, 3388, 3389, 3390, 3392, 3393, 3395, 3397,
-  3398, 3399, 3401, 3403, 3405, 3407, 3408, 3409,
-  3410, 3411, 3412, 3413, 3414, 3415, 3416, 3417,
-  3418, 3419, 3420, 3421, 3422, 3423, 3426, 3429,
-  3430, 3431, 3432, 3433, 3434, 3435, 3437, 3439,
-  3441, 3442, 3443, 3444, 3445, 3446, 3447, 3449,
-  3450, 3451, 3452, 3453, 3454, 3455, 3456, 3457,
-  3458, 3459, 3460, 3461, 3462, 3463, 3464, 3465,
-  3466, 3467, 3468, 3469, 3472, 3475, 3476, 3477,
-  3478, 3479, 3480, 3481, 3482, 3483, 3484, 3485,
-  3486, 3487, 3488, 3489, 3490, 3491, 3492, 3493,
-  3494, 3495, 3496, 3497, 3498, 3499, 3500, 3501,
-  3502, 3503, 3504, 3505, 3506, 3507, 3508, 3509,
-  3510, 3511, 3512, 3513, 3514, 3515, 3516, 3517,
-  3518, 3519, 3520, 3521, 3522, 3523, 3524, 3525,
-  3526, 3527, 3528, 3529, 3532, 3534, 3537, 3540,
-  3542, 3545, 3548, 3551, 3554, 3555, 3558, 3559,
-  3560, 3561, 3562, 3563, 3567, 3569, 3572, 3573,
-  3574, 3575, 3576, 3577, 3578, 3579, 3580, 3581,
-  3582, 3583, 3584, 3585, 3586, 3587, 3588, 3589,
-  3590, 3591, 3592, 3593, 3594, 3595, 3596, 3597,
-  3598, 3599, 3600, 3601, 3602, 3603, 3604, 3605,
-  3606, 3607, 3608, 3609, 3610, 3611, 3612, 3613,
-  3614, 3615, 3616, 3617, 3618, 3619, 3620, 3621,
-  3622, 3623, 3624, 3625, 3626, 3627, 3629, 3630,
-  3631, 3632, 3633, 3634, 3635, 3636, 3637, 3638,
-  3639, 3640, 3641, 3642, 3643, 3644, 3645, 3646,
-  3647, 3648, 3649, 3650, 3651, 3652, 3653, 3654,
-  3655, 3656, 3657, 3658, 3659, 3660, 3661, 3662,
-  3663, 3664, 3665, 3666, 3667, 3668, 3671, 3674,
-  3677, 3680, 3683, 3686, 3689, 3692, 3695, 3698,
-  3701, 3704, 3707, 3710, 3713, 3714, 3715, 3716,
-  3717, 3719, 3720, 3721, 3722, 3723, 3724, 3725,
-  3726, 3727, 3728, 3729, 3730, 3731, 3732, 3733,
-  3734, 3735, 3736, 3737, 3738, 3739, 3740, 3741,
-  3742, 3743, 3744, 3745, 3746, 3747, 3748, 3749,
-  3750, 3751, 3752, 3753, 3754, 3755, 3756, 3757,
-  3758, 3759, 3760, 3761, 3762, 3763, 3764, 3765,
-  3766, 3767, 3768, 3769, 3770, 3771, 3772, 3773,
-  3774, 3775, 3776, 3777, 3778, 3779, 3780, 3783,
-  3786, 3787, 3788, 3789, 3790, 3791, 3792, 3793,
-  3794, 3795, 3796, 3797, 3798, 3799, 3800, 3801,
-  3802, 3803, 3804, 3805, 3806, 3807, 3808, 3809,
-  3810, 3811, 3812, 3813, 3814, 3815, 3816, 3817,
-  3818, 3819, 3820, 3821, 3822, 3823, 3824, 3825,
-  3826, 3827, 3828, 3829, 3830, 3831, 3832, 3833,
-  3834, 3835, 3836, 3837, 3838, 3839, 3840, 3841,
-  3842, 3843, 3844, 3845, 3846, 3847, 3848, 3851,
-  3854, 3857, 3858, 3859, 3860, 3861, 3862, 3863,
-  3864, 3865, 3866, 3867, 3868, 3869, 3870, 3871,
-  3872, 3873, 3876, 3879, 3880, 3881, 3884, 3885,
-  3886, 3887, 3888, 3891, 3894, 3897, 3898, 3899,
-  3900, 3901, 3902, 3903, 3904, 3905, 3906, 3907,
-  3909, 3911, 3912, 3913, 3914, 3915, 3916, 3917,
-  3918, 3919, 3920, 3921, 3922, 3923, 3924, 3925,
-  3926, 3927, 3928, 3929, 3930, 3931, 3932, 3933,
-  3934, 3935, 3936, 3938, 3940, 3941, 3942, 3943,
-  3944, 3945, 3946, 3947, 3948, 3949, 3950, 3951,
-  3952, 3953, 3954, 3955, 3956, 3957, 3958, 3959,
-  3960, 3961, 3962, 3963, 3964, 3965, 3967, 3969,
-  3971, 3973, 3974, 3975, 3976, 3977, 3978, 3979,
-  3980, 3981, 3982, 3983, 3984, 3985, 3986, 3987,
-  3988, 3990, 3991, 3993, 3996, 3998, 3999, 4000,
-  4002, 4004, 4005, 4006, 4007, 4008, 4009, 4010,
-  4012, 4014, 4016, 4018, 4019, 4020, 4021, 4022,
-  4023, 4024, 4025, 4026, 4027, 4029, 4031, 4032,
-  4034, 4036, 4037, 4042, 4044, 4046, 4047, 4048,
-  4049, 4050, 4051, 4052, 4053, 4055, 4057, 4058,
-  4059, 4060, 4062, 4065, 4068, 4071, 4073, 4074,
-  4075, 4076, 4077, 4078, 4079, 4080, 4081, 4082,
-  4083, 4084, 4085, 4086, 4087, 4088, 4089, 4090,
-  4091, 4092, 4093, 4094, 4095, 4096, 4097, 4098,
-  4099, 4100, 4101, 4102, 4103, 4104, 4105, 4106,
-  4107, 4108, 4109, 4110, 4111, 4112, 4113, 4114,
-  4115, 4116, 4117, 4118, 4119, 4120, 4121, 4122,
-  4123, 4124, 4125, 4126, 4127, 4128, 4129, 4130,
-  4131, 4132, 4133, 4134, 4135, 4136, 4137, 4138,
-  4139, 4140, 4141, 4142, 4143, 4144, 4145, 4146,
-  4147, 4148, 4149, 4150, 4151, 4152, 4153, 4154,
-  4155, 4156, 4157, 4158, 4159, 4160, 4161, 4162,
-  4163, 4164, 4165, 4166, 4167, 4168, 4169, 4170,
-  4171, 4172, 4173, 4174, 4175, 4176, 4177, 4178,
-  4179, 4180, 4181, 4182, 4183, 4184, 4185, 4186,
-  4187, 4188, 4189, 4190, 4191, 4192, 4193, 4194,
-  4195, 4196, 4197, 4198, 4199, 4200, 4201, 4202,
-  4203, 4204, 4205, 4206, 4207, 4208, 4209, 4210,
-  4211, 4212, 4213, 4214, 4215, 4218, 4219, 4220,
-  4223, 4224, 4225, 4227, 4228, 4229, 4230, 4232,
-  4233, 4234, 4235, 4237, 4238, 4239, 4240, 4243,
-  4244, 4245, 4246, 4247, 4250, 4253, 4256, 4259,
-  4262, 4263, 4264, 4265, 4266, 4268, 4270, 4271,
-  4272, 4273, 4276, 4279, 4282, 4285, 4288, 4289,
-  4290, 4291, 4293, 4294, 4295, 4296, 4298, 4299,
-  4300, 4301, 4302, 4303, 4304, 4305, 4306, 4307,
-  4308, 4309, 4310, 4311, 4312, 4313, 4314, 4315,
-  4316, 4317, 4318, 4319, 4320, 4321, 4322, 4323,
-  4324, 4325, 4326, 4327, 4328, 4329, 4330, 4331,
-  4332, 4333, 4334, 4335, 4336, 4337, 4339, 4341,
-  4343, 4345, 4347, 4348, 4349, 4352, 4355, 4356,
-  4357, 4358, 4359
+  2065, 2066, 2067, 2068, 2069, 2070, 2073, 2075,
+  2077, 2079, 2081, 2083, 2085, 2087, 2089, 2091,
+  2093, 2095, 2097, 2099, 2101, 2103, 2105, 2107,
+  2109, 2111, 2113, 2115, 2117, 2119, 2121, 2123,
+  2125, 2127, 2129, 2131, 2133, 2135, 2137, 2139,
+  2141, 2143, 2145, 2147, 2149, 2151, 2153, 2155,
+  2157, 2159, 2161, 2163, 2165, 2167, 2169, 2171,
+  2173, 2175, 2177, 2179, 2181, 2183, 2185, 2187,
+  2189, 2191, 2193, 2195, 2197, 2199, 2201, 2203,
+  2205, 2207, 2209, 2211, 2213, 2215, 2217, 2219,
+  2221, 2223, 2225, 2227, 2229, 2231, 2233, 2235,
+  2237, 2239, 2241, 2243, 2245, 2247, 2249, 2251,
+  2253, 2255, 2257, 2259, 2261, 2263, 2265, 2267,
+  2269, 2271, 2273, 2275, 2277, 2279, 2281, 2283,
+  2285, 2287, 2289, 2291, 2293, 2295, 2297, 2299,
+  2301, 2303, 2305, 2307, 2309, 2311, 2313, 2315,
+  2317, 2319, 2321, 2323, 2325, 2327, 2329, 2331,
+  2333, 2335, 2337, 2339, 2341, 2343, 2345, 2347,
+  2349, 2351, 2353, 2355, 2357, 2359, 2361, 2363,
+  2365, 2367, 2369, 2371, 2373, 2375, 2377, 2379,
+  2381, 2383, 2385, 2387, 2389, 2391, 2393, 2395,
+  2397, 2399, 2401, 2403, 2405, 2407, 2409, 2411,
+  2413, 2415, 2417, 2419, 2421, 2423, 2425, 2427,
+  2429, 2431, 2433, 2435, 2437, 2439, 2441, 2443,
+  2445, 2447, 2449, 2451, 2453, 2455, 2460, 2462,
+  2467, 2469, 2471, 2476, 2478, 2480, 2482, 2487,
+  2489, 2491, 2493, 2497, 2503, 2505, 2510, 2512,
+  2514, 2516, 2518, 2520, 2522, 2524, 2526, 2528,
+  2529, 2530, 2531, 2533, 2534, 2535, 2536, 2537,
+  2538, 2540, 2541, 2542, 2543, 2545, 2547, 2549,
+  2551, 2553, 2555, 2557, 2559, 2561, 2563, 2565,
+  2567, 2569, 2573, 2574, 2575, 2577, 2581, 2585,
+  2587, 2591, 2595, 2596, 2597, 2599, 2601, 2603,
+  2605, 2610, 2614, 2618, 2620, 2622, 2624, 2626,
+  2627, 2629, 2631, 2633, 2635, 2637, 2639, 2641,
+  2643, 2645, 2647, 2649, 2651, 2653, 2655, 2657,
+  2659, 2661, 2663, 2665, 2667, 2669, 2671, 2672,
+  2673, 2675, 2677, 2678, 2679, 2682, 2685, 2688,
+  2691, 2693, 2695, 2697, 2699, 2701, 2703, 2704,
+  2705, 2706, 2708, 2712, 2714, 2716, 2722, 2726,
+  2727, 2728, 2729, 2730, 2731, 2732, 2733, 2737,
+  2739, 2741, 2745, 2747, 2749, 2751, 2753, 2755,
+  2757, 2759, 2761, 2763, 2765, 2767, 2769, 2771,
+  2773, 2774, 2777, 2780, 2785, 2790, 2793, 2796,
+  2799, 2802, 2807, 2812, 2815, 2818, 2820, 2822,
+  2824, 2826, 2828, 2830, 2832, 2833, 2835, 2837,
+  2839, 2841, 2843, 2844, 2845, 2846, 2850, 2854,
+  2856, 2860, 2864, 2868, 2872, 2876, 2878, 2882,
+  2884, 2886, 2888, 2890, 2892, 2894, 2896, 2898,
+  2899, 2901, 2903, 2905, 2907, 2909, 2911, 2913,
+  2915, 2916, 2917, 2918, 2919, 2920, 2921, 2922,
+  2923, 2924, 2926, 2928, 2930, 2932, 2934, 2936,
+  2937, 2939, 2941, 2943, 2945, 2946, 2947, 2949,
+  2951, 2953, 2955, 2957, 2959, 2961, 2963, 2964,
+  2965, 2966, 2967, 2970, 2973, 2975, 2978, 2979,
+  2980, 2982, 2983, 2985, 2986, 2987, 2989, 2991,
+  2992, 2993, 2994, 2995, 2996, 2999, 3004, 3009,
+  3014, 3019, 3022, 3027, 3032, 3034, 3036, 3038,
+  3040, 3041, 3042, 3044, 3046, 3048, 3050, 3052,
+  3054, 3056, 3057, 3058, 3059, 3060, 3061, 3062,
+  3067, 3072, 3073, 3074, 3075, 3076, 3077, 3078,
+  3079, 3080, 3081, 3082, 3083, 3084, 3085, 3086,
+  3087, 3088, 3089, 3090, 3091, 3092, 3093, 3094,
+  3095, 3096, 3097, 3098, 3099, 3100, 3101, 3102,
+  3103, 3104, 3105, 3106, 3107, 3108, 3109, 3110,
+  3111, 3112, 3113, 3114, 3115, 3116, 3117, 3118,
+  3119, 3120, 3121, 3122, 3123, 3124, 3125, 3126,
+  3127, 3128, 3129, 3130, 3131, 3132, 3133, 3134,
+  3135, 3136, 3137, 3138, 3139, 3140, 3141, 3142,
+  3143, 3144, 3145, 3146, 3147, 3148, 3149, 3150,
+  3151, 3152, 3153, 3154, 3155, 3156, 3157, 3158,
+  3159, 3160, 3161, 3162, 3163, 3164, 3165, 3166,
+  3167, 3168, 3169, 3170, 3171, 3172, 3173, 3174,
+  3175, 3176, 3177, 3178, 3179, 3180, 3181, 3182,
+  3183, 3184, 3185, 3186, 3187, 3188, 3189, 3190,
+  3191, 3192, 3193, 3194, 3195, 3196, 3197, 3198,
+  3199, 3200, 3201, 3202, 3203, 3204, 3205, 3206,
+  3207, 3208, 3209, 3210, 3211, 3212, 3213, 3214,
+  3215, 3216, 3217, 3218, 3219, 3220, 3221, 3222,
+  3223, 3224, 3225, 3226, 3227, 3228, 3229, 3230,
+  3231, 3232, 3233, 3234, 3235, 3236, 3237, 3238,
+  3239, 3240, 3241, 3242, 3243, 3244, 3245, 3246,
+  3247, 3248, 3249, 3250, 3251, 3252, 3253, 3254,
+  3255, 3256, 3257, 3258, 3259, 3260, 3261, 3262,
+  3263, 3264, 3265, 3266, 3267, 3268, 3269, 3270,
+  3271, 3272, 3273, 3275, 3277, 3278, 3279, 3280,
+  3281, 3282, 3283, 3284, 3285, 3286, 3287, 3288,
+  3289, 3290, 3291, 3292, 3293, 3294, 3295, 3296,
+  3297, 3298, 3299, 3300, 3301, 3302, 3303, 3304,
+  3305, 3307, 3309, 3311, 3313, 3314, 3315, 3316,
+  3317, 3318, 3319, 3320, 3321, 3322, 3323, 3324,
+  3325, 3326, 3328, 3329, 3330, 3331, 3333, 3334,
+  3335, 3336, 3337, 3338, 3339, 3340, 3341, 3342,
+  3343, 3344, 3345, 3346, 3347, 3348, 3349, 3350,
+  3351, 3352, 3353, 3354, 3355, 3356, 3357, 3358,
+  3359, 3360, 3361, 3362, 3363, 3364, 3365, 3366,
+  3367, 3368, 3369, 3370, 3371, 3372, 3373, 3374,
+  3376, 3378, 3379, 3380, 3382, 3383, 3385, 3387,
+  3388, 3389, 3391, 3393, 3395, 3397, 3398, 3399,
+  3400, 3401, 3402, 3403, 3404, 3405, 3406, 3407,
+  3408, 3409, 3410, 3411, 3412, 3413, 3416, 3419,
+  3420, 3421, 3422, 3423, 3424, 3425, 3427, 3429,
+  3431, 3432, 3433, 3434, 3435, 3436, 3437, 3439,
+  3440, 3441, 3442, 3443, 3444, 3445, 3446, 3447,
+  3448, 3449, 3450, 3451, 3452, 3453, 3454, 3455,
+  3456, 3457, 3458, 3459, 3462, 3465, 3466, 3467,
+  3468, 3469, 3470, 3471, 3472, 3473, 3474, 3475,
+  3476, 3477, 3478, 3479, 3480, 3481, 3482, 3483,
+  3484, 3485, 3486, 3487, 3488, 3489, 3490, 3491,
+  3492, 3493, 3494, 3495, 3496, 3497, 3498, 3499,
+  3500, 3501, 3502, 3503, 3504, 3505, 3506, 3507,
+  3508, 3509, 3510, 3511, 3512, 3513, 3514, 3515,
+  3516, 3517, 3518, 3519, 3522, 3524, 3527, 3530,
+  3532, 3535, 3538, 3541, 3544, 3545, 3548, 3549,
+  3550, 3551, 3552, 3553, 3557, 3559, 3562, 3563,
+  3564, 3565, 3566, 3567, 3568, 3569, 3570, 3571,
+  3572, 3573, 3574, 3575, 3576, 3577, 3578, 3579,
+  3580, 3581, 3582, 3583, 3584, 3585, 3586, 3587,
+  3588, 3589, 3590, 3591, 3592, 3593, 3594, 3595,
+  3596, 3597, 3598, 3599, 3600, 3601, 3602, 3603,
+  3604, 3605, 3606, 3607, 3608, 3609, 3610, 3611,
+  3612, 3613, 3614, 3615, 3616, 3617, 3619, 3620,
+  3621, 3622, 3623, 3624, 3625, 3626, 3627, 3628,
+  3629, 3630, 3631, 3632, 3633, 3634, 3635, 3636,
+  3637, 3638, 3639, 3640, 3641, 3642, 3643, 3644,
+  3645, 3646, 3647, 3648, 3649, 3650, 3651, 3652,
+  3653, 3654, 3655, 3656, 3657, 3658, 3661, 3664,
+  3667, 3670, 3673, 3676, 3679, 3682, 3685, 3688,
+  3691, 3694, 3697, 3700, 3703, 3704, 3705, 3706,
+  3707, 3709, 3710, 3711, 3712, 3713, 3714, 3715,
+  3716, 3717, 3718, 3719, 3720, 3721, 3722, 3723,
+  3724, 3725, 3726, 3727, 3728, 3729, 3730, 3731,
+  3732, 3733, 3734, 3735, 3736, 3737, 3738, 3739,
+  3740, 3741, 3742, 3743, 3744, 3745, 3746, 3747,
+  3748, 3749, 3750, 3751, 3752, 3753, 3754, 3755,
+  3756, 3757, 3758, 3759, 3760, 3761, 3762, 3763,
+  3764, 3765, 3766, 3767, 3768, 3769, 3770, 3773,
+  3776, 3777, 3778, 3779, 3780, 3781, 3782, 3783,
+  3784, 3785, 3786, 3787, 3788, 3789, 3790, 3791,
+  3792, 3793, 3794, 3795, 3796, 3797, 3798, 3799,
+  3800, 3801, 3802, 3803, 3804, 3805, 3806, 3807,
+  3808, 3809, 3810, 3811, 3812, 3813, 3814, 3815,
+  3816, 3817, 3818, 3819, 3820, 3821, 3822, 3823,
+  3824, 3825, 3826, 3827, 3828, 3829, 3830, 3831,
+  3832, 3833, 3834, 3835, 3836, 3837, 3838, 3841,
+  3844, 3847, 3848, 3849, 3850, 3851, 3852, 3853,
+  3854, 3855, 3856, 3857, 3858, 3859, 3860, 3861,
+  3862, 3863, 3866, 3869, 3870, 3871, 3874, 3875,
+  3876, 3877, 3878, 3881, 3884, 3887, 3888, 3889,
+  3890, 3891, 3892, 3893, 3894, 3895, 3896, 3897,
+  3899, 3901, 3902, 3903, 3904, 3905, 3906, 3907,
+  3908, 3909, 3910, 3911, 3912, 3913, 3914, 3915,
+  3916, 3917, 3918, 3919, 3920, 3921, 3922, 3923,
+  3924, 3925, 3926, 3928, 3930, 3931, 3932, 3933,
+  3934, 3935, 3936, 3937, 3938, 3939, 3940, 3941,
+  3942, 3943, 3944, 3945, 3946, 3947, 3948, 3949,
+  3950, 3951, 3952, 3953, 3954, 3955, 3957, 3959,
+  3961, 3963, 3964, 3965, 3966, 3967, 3968, 3969,
+  3970, 3971, 3972, 3973, 3974, 3975, 3976, 3977,
+  3978, 3980, 3981, 3983, 3986, 3988, 3989, 3990,
+  3992, 3994, 3995, 3996, 3997, 3998, 3999, 4000,
+  4002, 4004, 4006, 4008, 4009, 4010, 4011, 4012,
+  4013, 4014, 4015, 4016, 4017, 4019, 4021, 4022,
+  4024, 4026, 4027, 4032, 4034, 4036, 4037, 4038,
+  4039, 4040, 4041, 4042, 4043, 4045, 4047, 4048,
+  4049, 4050, 4052, 4055, 4058, 4061, 4063, 4064,
+  4065, 4066, 4067, 4068, 4069, 4070, 4071, 4072,
+  4073, 4074, 4075, 4076, 4077, 4078, 4079, 4080,
+  4081, 4082, 4083, 4084, 4085, 4086, 4087, 4088,
+  4089, 4090, 4091, 4092, 4093, 4094, 4095, 4096,
+  4097, 4098, 4099, 4100, 4101, 4102, 4103, 4104,
+  4105, 4106, 4107, 4108, 4109, 4110, 4111, 4112,
+  4113, 4114, 4115, 4116, 4117, 4118, 4119, 4120,
+  4121, 4122, 4123, 4124, 4125, 4126, 4127, 4128,
+  4129, 4130, 4131, 4132, 4133, 4134, 4135, 4136,
+  4137, 4138, 4139, 4140, 4141, 4142, 4143, 4144,
+  4145, 4146, 4147, 4148, 4149, 4150, 4151, 4152,
+  4153, 4154, 4155, 4156, 4157, 4158, 4159, 4160,
+  4161, 4162, 4163, 4164, 4165, 4166, 4167, 4168,
+  4169, 4170, 4171, 4172, 4173, 4174, 4175, 4176,
+  4177, 4178, 4179, 4180, 4181, 4182, 4183, 4184,
+  4185, 4186, 4187, 4188, 4189, 4190, 4191, 4192,
+  4193, 4194, 4195, 4196, 4197, 4198, 4199, 4200,
+  4201, 4202, 4203, 4204, 4205, 4208, 4209, 4210,
+  4213, 4214, 4215, 4217, 4218, 4219, 4220, 4222,
+  4223, 4224, 4225, 4227, 4228, 4229, 4230, 4233,
+  4234, 4235, 4236, 4237, 4240, 4243, 4246, 4249,
+  4252, 4253, 4254, 4255, 4256, 4258, 4260, 4261,
+  4262, 4263, 4266, 4269, 4272, 4275, 4278, 4279,
+  4280, 4281, 4283, 4284, 4285, 4286, 4288, 4289,
+  4290, 4291, 4292, 4293, 4294, 4295, 4296, 4297,
+  4298, 4299, 4300, 4301, 4302, 4303, 4304, 4305,
+  4306, 4307, 4308, 4309, 4310, 4311, 4312, 4313,
+  4314, 4315, 4316, 4317, 4318, 4319, 4320, 4321,
+  4322, 4323, 4324, 4325, 4326, 4327, 4329, 4331,
+  4333, 4335, 4337, 4338, 4339, 4342, 4345, 4346,
+  4347, 4348, 4349
 };
 
 /* i386 mnemonics table.  */
-- 
2.46.0