[PATCH 1/2] Support Intel MOVRS

[Jiang, Haochen]

> From: Jan Beulich <jbeulich@suse.com>
> Sent: Monday, January 6, 2025 4:39 PM
> 
> On 30.12.2024 08:39, Jiang, Haochen wrote:
> >> From: Jan Beulich <jbeulich@suse.com>
> >> Sent: Friday, December 27, 2024 8:27 PM
> >>
> >> On 24.12.2024 10:24, Haochen Jiang wrote:
> >>> --- a/opcodes/i386-opc.tbl
> >>> +++ b/opcodes/i386-opc.tbl
> >>> @@ -3554,3 +3554,17 @@ vcomxs<sdh>, 0x<sdh:spfx>2f, AVX10_2,
> >>> Modrm|EVexLIG|<sdh:spc1>|<sdh:vexw>|Disp8M
> >>>  vucomxs<sdh>, 0x<sdh:spfx>2e, AVX10_2,
> >>> Modrm|EVexLIG|<sdh:spc1>|<sdh:vexw>|Disp8MemShift|NoSuf|SAE, {
> >>> RegXMM|<sdh:elem>|Unspecified|BaseIndex, RegXMM }
> >>>
> >>>  // AVX10.2 instructions end.
> >>> +
> >>> +// MOVRS instructions.
> >>> +
> >>> +prefetchrst2, 0xf18/4, MOVRS, Modrm|Anysize|IgnoreSize|NoSuf, {
> >>> +BaseIndex }
> >>> +
> >>> +movrs, 0x8a, MOVRS&x64,
> >>> +Modrm|Space0F38|No_wSuf|No_lSuf|No_sSuf|No_qSuf, {
> >>> +Byte|Unspecified|BaseIndex, Reg8 } movrs, 0x8b, MOVRS&x64,
> >>> +Modrm|Anysize|Space0F38|CheckOperandSize|No_bSuf|No_sSuf, {
> >>> +Word|Dword|Qword|Unspecified|BaseIndex, Reg16|Reg32|Reg64 }
> >> movrs,
> >>> +0x8a, MOVRS&APX_F,
> >>>
> >>
> +Modrm|EVex128|EVexMap4|VexW0|No_wSuf|No_lSuf|No_sSuf|No_qSuf
> >> , {
> >>> +Byte|Unspecified|BaseIndex, Reg8 } movrs, 0x8b, MOVRS&APX_F,
> >>> +Modrm|CheckOperandSize|EVex128|EVexMap4|No_bSuf|No_sSuf, {
> >>> +Word|Dword|Qword|Unspecified|BaseIndex, Reg16|Reg32|Reg64 }
> >>
> >> These want to leverage W if at all possible, allowing to go from 4 to 2
> >> templates.
> >
> > It is not a VEX/EVEX promotion, but a legacy/EVEX promotion. Could we do
> > that?
> >
> > If we could, the problem here is still MOVRS is not 64-bit default. Then the
> > non-APX part needs x64, making it multiple CPUIDs. Maybe it also needs
> > work around in cpu_flags_match second assert just like
> > AMX_MOVRS & AMX_TRANSPOSE. At least we could check the all.bitfield
> > to let them skip that assert.
> 
> Perhaps a misunderstanding? I talk about our W attribute in the opcode table,
> not EVEX.W.
> 

VexW0 should be removed per my understanding although I am still waiting for
clarification from HW team on that. My problem and statement is on "allowing
to go from 4 to 2 templates". It seems to me not that doable. Could you help
explain on that part?

Thx,
Haochen