[PATCH] x86/APX: Don't promote AVX512 instructions out of APX spec

[H.J. Lu]

On Mon, Sep 23, 2024, 7:22 PM Jan Beulich <jbeulich@suse.com> wrote:

> On 23.09.2024 13:14, Cui, Lili wrote:
> >
> >
> >> -----Original Message-----
> >> From: Jan Beulich <jbeulich@suse.com>
> >> Sent: Monday, September 23, 2024 4:30 PM
> >> To: Cui, Lili <lili.cui@intel.com>
> >> Cc: Binutils <binutils@sourceware.org>; H.J. Lu <hjl.tools@gmail.com>
> >> Subject: Re: [PATCH] x86/APX: Don't promote AVX512 instructions out of
> APX
> >> spec
> >>
> >> On 23.09.2024 09:51, Cui, Lili wrote:
> >>> Jan, I'm sorry that I didn't notice you checking in these patches at
> first,
> >> although I have been against this kind of promotion in the previous
> discussion.
> >> But it's really a bit radical to make this kind of out-of-spec
> promotion by default.
> >> Would you rather put them under options? After all, these conversions
> are very
> >> clever.
> >>
> >> I continue to think they want doing by default, with possibly a way to
> turn them
> >> off (compiler mode) and/or diagnose them (perhaps no more than "info"
> >> level).
> >>
> >
> > The benefit of this optimization is that when the hand-written assembler
> makes a mistake in writing few VEX instructions, we can promote it to the
> EVEX instructions. The cost is to let the compiler add a separate option
> when compiling or define different behaviors for the compiler and the
> hand-written assembler mode (If there is a way to do this, inline assembler
> and hand-written assembly behavior is inconsistent, this inconsistent
> behavior will confuse people). Other compilers also strictly enforce errors
> for this illegal Egpr usage. We cannot promote all illegal Egpr usage, if
> there is such an improvement,
>
> I'm relatively sure this could be arranged for in many of the cases, just
> not
> with single-insn replacements. I didn't want to go _that_ far ...
>

Assembly programmers will write assmebly codes
following the spec so that the source will work for
all compilers/assemblers.  It makes little senses to
add these instructions to GNU assembler, especially by default.


> Jan
>
> > it may be worth making such a change.
> >
> > Thanks,
> > Lili.
> >
> >> Jan
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20240924/7b01881b/attachment.htm>