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

[Jan Beulich]

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.

Jan