[PATCH 4/5] x86/APX: extend SSE2AVX coverage
Cui, Lili
lili.cui@intel.com
Mon Apr 8 07:38:12 GMT 2024
> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Monday, April 8, 2024 2:25 PM
> To: 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 07.04.2024 03:48, Cui, Lili wrote:
> >> 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.
>
> Just to mention it - I've already changed this, in less ugly a way than I first
> feared it would be.
>
Ok, thanks.
> And just to mention this as well: From midday today I'll be gone for a little
> over a week; please expect delayed responses (should any be needed
> anywhere).
>
Have a nice holiday and I'll send out the APX ZU patch when you get back.
Lili.
More information about the Binutils
mailing list