Re: [PATCH 4/6] x86: fold SSE2AVX and their base MMX/SSE templates

["H.J. Lu" <hjl.tools@gmail.com>]

On Fri, Mar 26, 2021 at 3:51 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> This way not only the overall (source) table size shrinks by quite a
> bit and the risk of related templates going out of sync with one another
> gets lowered, but also (dis)similarities between neighboring templates
> become easier to spot.
>
> Note that for certain SSE2AVX templates this results in benign attribute
> changes:
> - LDMXCSR and STMXCSR: NoAVX gets set,
> - MOVMSKPS, PMOVMSKB, PEXTR{B,W} (register destination), and PINSR{B,W}
>   (register source): IgnoreSize and NoRex64 get set,
> - CVT{DQ,PS}2PD, CVTSD2SS, MOVMSKPD, MOVDDUP, PMOV{S,Z}X{BW,WD,DQ}, and
>   ROUNDSD: NoRex64 gets set,
> - CVTSS2SD, INSERTPS, PEXTRW (memory destination), PINSRW (memory
>   source), and PMOV{S,Z}X{BD,WQ,BQ}: IgnoreSize gets set.
> Similarly the "normal" (non-SSE2AVX)
> - non-64-bit CVTS{I,S}2SD forms get NoRex64 set,
> - CMP{EQ,ORD,NEQ,UNORD}{P,S}{S,D} forms get C set,
> all again in a benign way.
>
> The remaining differences in the generated table are due to re-ordering
> of entries in the course of being folded into templates.
>
> opcodes/
> 2021-03-XX  Jan Beulich  <jbeulich@suse.com>
>
>         * i386-opc.tbl (mmx, sse, sse2, sse3, ssse3, sse41, sse42, aes,
>         pclmul, gfni): New templates. Use them wherever possible. Move
>         SSE4.1 pextrw into respective section.
>         * i386-tbl.h: Re-generate.
> ---
> Considering the setting of C turned out benign for legacy encoding
> templates (I did the CMP<>{P,S}{S,D} conversion rather late in the
> process, as it was there where I expected problems), it would be an
> option to drop the "comm" template parameters, at the expense of further
> legacy encoding templates getting C set. An alternative would be to have
> i386-gen recognize at least simple & expressions, allowing use of e.g.
> ...|<sse_frel:comm>&<sse:comm>|... in the templates.
>
> It might further be possible to live with VexVVVV getting set on legacy
> encoding templates, which would allow elimination of another template
> parameter in a number of cases.
>

I don't have a preference.  Please feel free to do something reasonable.

Thanks.

--
H.J.