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 11:46 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> 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?
>

I don't think it is a problem to begin with.


-- 
H.J.