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

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

> 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.  GFNI SSE does not support eGPR-s, I'm not sure if we should give it an error instead of converting it.

> Note that LDDQU is represented as VMOVDQU32 (and the prior use of the
> sse3 template needs dropping, to get the order right).
> 

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

> Note further that in a few cases, due to the use of templates, AVX512VL
> is used when AVX512F would suffice. Since AVX10 is the main reference,
> this shouldn't be too much of a problem.
> ---

Yes, agreed.

> To preempt the question: If we weren't to do this (i.e. leave legacy-
> encoded SIMD insns using eGPR-s alone), I'd raise the counter question
> of why these insns are supported by APX then in the first place.
> 
> I'm tempted to "convert" legacy encoded insns in maps 2 and 3 even
> without -msse2avx. Thoughts?

I was a little worried about this conversion, so I asked a few people for their opinions, they found this approach a bit unacceptable, here are some ideas I collected.

1. The compiler will do this during the backend instruction selection phase. Binutils should only do instruction translation, not instruction selection.
2. We can only convert some instructions, not all instructions. When users use eGPR-s illegally, some will report an error, while others will not, which is very confusing.
3. Binutils needs to report errors for illegal instructions to ensure the correctness of the compiler.
4. I don't know if there are any machines in the future that don't expect to generate EVEX instructions.

> 
> Should we also cover RCP{P,S}S and RSQRT{P,S}S (via VRCP14{P,S}S /
> VSQRT14{P,S}S)? The latter provide slightly better precision results,
> but is that a potential issue?
> 

As far as I know, there should be no problem.

> By using a mask register (which supposedly shouldn't be used by legacy
> SIMD code) we could likely convert further insns (by emitting a pair of
> replacement ones).
> 
> What about SHA and KeyLocker insns not using eGPR-s? Their legacy
> encodings could be replaced by EVEX ones, too, provided that's a gain:
> Version 003 of the doc doesn't clarify whether, like other VEX/EVEX
> insns and unlike legacy ones, register bits beyond bit 127 would be
> cleared. That's the whole purpose of the SSE2AVX insns, after all. Yet
> of course there's the problem here that then such insns (not using any
> eGPR in their operands) would suddenly gain a dependency of the
> resulting code on APX_F (and not AVX512* / AVX10). Perhaps for these
> we'd really need -msse2apx then.
> 

If the CPU does not support the avx512 instruction, Binutils directly convert it, which will cause segment fault. It does seem like a new option is needed. These two instructions may change in the future, we can wait and see if this is necessary.

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

Regards,
Lili.