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

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

> -----Original Message-----
> From: Jiang, Haochen <haochen.jiang@intel.com>
> Sent: Wednesday, April 3, 2024 5:17 PM
> To: Beulich, Jan <JBeulich@suse.com>; Cui, Lili <lili.cui@intel.com>
> Cc: H.J. Lu <hjl.tools@gmail.com>; Binutils <binutils@sourceware.org>
> Subject: RE: [PATCH 4/5] x86/APX: extend SSE2AVX coverage
> 
> 
> 
> > On 03.04.2024 09:59, Cui, Lili wrote:
> > >>> 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?
> >
> > That's a question I've tentatively answered with "No". SSE => VEX
> > requires systems supporting AVX. SSE-with-eGPR requires systems with
> APX.
> > SSE-with-eGPR => EVEX similarly can rely on APX being there, and I
> > expect all such systems will support at least AVX10/128. If that is
> > deemed a wrong assumption, then indeed we may need to consider adding
> > a new option (but not -msse2avx512 as you suggest further down, as SSE
> > only ever covers 128- bit operations; -msse2avx10 maybe).
> 
> Just to clarify one thing, is the behavior change for -msse2avx happen only
> with EGPRs?
> 
> If answer is no, no matter the assumption is right or not, I suppose the
> problem is if we change the behavior for legacy -msse2avx to also promote to
> EVEX silently, from my understanding, it will cause on current hybrid clients
> and upcoming Sierra Forest and Clearwater Forest, EVEX instructions will
> appear under these platforms, which is not aligned with previous behavior
> for -msse2avx. Eventually it will crash since on those machines, there are no
> EVEX instructions. It might be a surprise to users.
> 

For all sse2avx instructions, we put AVX before the AVX512 template, so only Egpr will trigger sse to evex. My previous understanding was wrong.

Lili.