Re: [PATCH v2 9/9] x86: correct VFPCLASSP{S,D} operand size handling

[Jan Beulich <jbeulich at suse dot com>]

On 04.11.2019 18:20,  H.J. Lu  wrote:
> On Mon, Nov 4, 2019 at 2:21 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 31.10.2019 19:07,  H.J. Lu  wrote:
>>> On Thu, Oct 31, 2019 at 2:39 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>
>>>> On 30.10.2019 23:40,  H.J. Lu  wrote:
>>>>> On Wed, Oct 30, 2019 at 1:03 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>
>>>>>> On 29.10.2019 20:16, H.J. Lu wrote:
>>>>>>> On Mon, Oct 28, 2019 at 1:10 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>>>>>>
>>>>>>>> With AVX512VL disabled (e.g. when writing code for the Knights family
>>>>>>>> of processors) these insns aren't ambiguous when used with a memory
>>>>>>>> source, and hence should be accepted without suffix or operand size
>>>>>>>> specifier. When AVX512VL is enabled, to be consistent with this as
>>>>>>>> well as other ambiguous operand size handling it seems better to just
>>>>>>>> wanrn about the ambiguity in AT&T mode, and still default to 512-bit
>>>>>>>> operands (on the assumption that the code may have been written without
>>>>>>>> AVX512VL in mind yet).
>>>>>>>
>>>>>>> There is no need for this.   Memory size or suffix is always needed for them.
>>>>>>
>>>>>> It is not - what you say (again) is your private opinion, not (afaict)
>>>>>> something based on some objective criteria. If I'm missing something
>>>>>> here, please clarify, but recall that we've been discussing this before.
>>>>>>
>>>>>
>>>>> As I remembered, I didn't believe they should be treated differently,
>>>>> depending on AVX512VL.  One should be able to tell what the operand
>>>>> size is without checking if AVX512VL was disabled or not when the assembly
>>>>> file was assembled.
>>>>
>>>> Well - I understand this position of yours, but I can only repeat: To
>>>> me this is your personal preference, not an objective criteria. Let's
>>>> take PUSH/POP for comparison: Original 16-bit code may have been
>>>> written without the i386 in mind. Why would you enforce on people to
>>>> append W suffixes just because the assembler becomes i386 (and hence
>>>> 32-bit operand) aware? An indeed - gas doesn't require suffixes here,
>>>> silently defaulting to the default size implied by the mode specified.
>>>> It's even more relaxed there - the defaults get used irrespective of
>>>> any .arch settings.
>>>>
>>>> IOW I continue to think that it should be the programmer's choice
>>>> whether to imply CPU capability restrictions for their own code. It's
>>>> not like I'm forbidding the use of the suffix / operand size specifier
>>>> when none is actually needed.
>>>>
>>>
>>> Assembler accepts all instructions by default.   Interpret an instruction
>>> based on ISA doesn't buy much and may lead confusions.
>>
>> Yet _if_ someone cares to restrict the set of accepted insns to just
>> what they mean to target, then it'll be (at least) equally confusing
>> for the assembler to not accept an unambiguous (under the given
>> constraints) mnemonic. IOW I still don't understand why you object
>> to letting programmers decide what they prefer, and instead want to
>> "dictate" your view onto everyone.
>>
> 
> Assemblers have been behaving this way for a long time.  I don't
> think we should change it now.

I.e. bugs present for a long time shouldn't be fixed? Only ones
recently introduced should be?

Jan