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

[H.J. Lu]

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?

> though: I may not again first discuss what to do, I may simply revert
> commits of yours that were done while there were pending objections, or
> when you didn't even give people time to object.
>
> Jan



-- 
H.J.