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

[Jan Beulich]

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
on potentially controversial changes you ought to allow a reasonable
amount of time between submitting and committing.

Jan