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

[H.J. Lu]

On Tue, Sep 24, 2024, 6:53 PM Jan Beulich <jbeulich@suse.com> wrote:

> On 24.09.2024 12:21, H.J. Lu wrote:
> > On Tue, Sep 24, 2024 at 6:04 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 23.09.2024 23:42, H.J. Lu wrote:
> >>> 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
> >>>>>>
> >>>>>> 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.
> >>
> >> Well, I continue to disagree, but I guess I'll leave it at that. Just
> >> to be done here, even if really I shouldn't be letting you get through
> >> once again with playing against the rules. For the future be forewarned,
> >
> > You keep saying the rules.  What are the rules?
>
> It should go without saying that you cannot commit anything that has an
> unresolved objection. And I've mentioned numerous times that especially
>

Are you suggesting anyone can hold the project as hostage?

on potentially controversial changes you ought to allow a reasonable
> amount of time between submitting and committing.
>

I believe I am now doing that unless it is a very obvious fix.



> Jan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20240924/18ce0fa3/attachment.htm>