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

[Jan Beulich]

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