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

[H.J. Lu]

On Tue, Sep 24, 2024 at 7:19 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 24.09.2024 12:58, H.J. Lu wrote:
> > 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?
>
> Of course not. But disagreements need resolving. If someone objects and
> then doesn't any further participate in the resolution, the objection
> will "expire" at some point. And of course it is possible to identify
> objections as unsubstantiated, or for a maintainer to override a non-
> maintainer's objection. But if, as in the case here, two equal
> maintainters disagree, it is inappropriate to simply "force through"
> one's view by committing stuff. In such (imo rare) cases where
> agreement cannot otherwise be reached, arbitration may be needed. That
> would imo typically mean involving Nick. I don't think it would have
> required to go this far in the case here though, if only you had been
> willing to actually provide a better (less arbitrary) justification for
> the revert.
>
> Jan

Assembly programmers will write APX assembly codes following the APX
spec so that the source will work for all compilers/assemblers.  This is a
good enough reason to me.

-- 
H.J.