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

["H.J. Lu" <hjl dot tools at gmail dot com>]

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.

-- 
H.J.