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

[Jan Beulich]

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

We should convert whatever's possible to convert. I'll re-consider the VexW
part following your comment (without promising that I'll undo it; in
particular I don't see any hidden dangers).

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

I don't think doc adjustment is needed here. We already have at least one
example where the mnemonic also changes: CVTPI2PD -> VCVTDQ2PD.

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

Okay, I'll bin this (vague) plan then.

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

Well, this has resolved itself by the insn groups having been removed in
version 4 of the spec.

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

Jan