[PATCH 4/5] x86/APX: extend SSE2AVX coverage

[Cui, Lili]

> > This conversion is clever, although the mnemonic has changed, but
> considering it is controlled by -msse2avx, maybe we can mention in the
> option that it might change the mnemonic. Judging from the option name
> alone, it is difficult for users to predict that the mnemonic will change
> (traditionally, it seems to just add V).
> 
> I don't think doc adjustment is needed here. We already have at least one
> example where the mnemonic also changes: CVTPI2PD -> VCVTDQ2PD.
> 

Oh, there has been such a conversion before. Another thing that comes to mind is that sse2avx was previously used to support sse to vex conversion. This option works on machines that don't support evex. We now extend sse to evex, which makes this option unavailable on machines that do not support the evex instruction (e.g. hybrid machines like Alderlake). Do you think we should add a new option?

> >> Should we also convert %xmm<N>-only templates (to consistently permit
> >> use of {evex})? Or should we reject use of {evex}, but then also that
> >> of {vex}/{vex3}?
> >
> > Do you mean SHA and KeyLocker?
> 
> No, I mean templates with all XMM operands and no memory ones. Such
> don't use eGPR-s, yet could be converted to their EVEX counterparts, too (by
> way of the programmer adding {evex} to the _legacy_ insn). Hence the
> question on how to treat {evex} there, and then also {vex} / {vex3}. Take, for
> example, MOVHLPS or MOVLHPS.

I'm not sure if you want to support this conversion under -sse2avx. I think this conversion is only used by people writing assembler by hand. As for adding a prefix to convert sse to vex or evex, I think this requirement doesn't make much sense at the moment, maybe in the future if evex is faster than the vex instruction we can provide an option like sse2avx512 to achieve this conversion.

Thanks,
Lili.