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

[Jan Beulich <jbeulich at suse dot com>]

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.

Jan