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

["Cui, Lili" <lili.cui@intel.com>]

> On 29.03.2024 10:10, Cui, Lili wrote:
> >> Legacy encoded SIMD insns are converted to AVX ones in that mode.
> >> When eGPR-s are in use, i.e. with APX, convert to AVX10 insns (where
> >> available; there are quite a few which can't be converted).
> >>
> >> For GFNI alter the gfni template such that VexW would be emitted even
> >> for the SSE templates: There the attribute is simply meaningless, but
> >> it simplifies the template quite a bit.
> >
> > For this part, although adding VexW to the SSE template is more concise, it
> also breaks the rules and creates hidden dangers, it feels a bit unworthy.
> 
> Coming back to this: What rules is this breaking?
> 

Normally we only add VexW to VEX and EVEX formats, not to legacy formats. Once someone wants to use VexW to distinguish them, he will find that there is a special one there. 
But this is just an assumption, we have other flags to distinguish them. I won't insist on this issue, it won't have much impact.

> I can see your point of "hidden dangers", yet I'm unsure about drawing the
> conclusion that it's "unworthy": The <gfni> template would need dropping
> altogether in the alternative approach, doubling the number of insn
> template lines. That's not _that_ much, but still worthwhile to weigh against
> those latent risks.
> 
> >  GFNI SSE does not support eGPR-s, I'm not sure if we should give it an error
> instead of converting it.
> 
> Well, this would mean not converting various others either. One of the goals,
> however, was to allow conversion of as many of the insns as possible, even if
> their legacy forms has no REX2 representation.
> 

Since they are under the sse2mmx option, I think this is OK.

Thanks,
Lili.