Re: [PATCH 5/7] x86: re-work insn/suffix recognition

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

On Mon, Sep 5, 2022 at 11:40 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 26.08.2022 20:46, H.J. Lu wrote:
> > On Fri, Aug 26, 2022 at 2:26 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 23.08.2022 04:00, H.J. Lu wrote:
> >>> On Fri, Aug 19, 2022 at 1:28 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>
> >>>> On 18.08.2022 17:14, H.J. Lu wrote:
> >>>>> On Wed, Aug 17, 2022 at 11:24 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>>
> >>>>>> On 17.08.2022 22:29, H.J. Lu wrote:
> >>>>>>> On Tue, Aug 16, 2022 at 12:32 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>>>>
> >>>>>>>> x86: re-work insn/suffix recognition
> >>>>>>>>
> >>>>>>>> Having templates with a suffix explicitly present has always been
> >>>>>>>> quirky. Introduce a 2nd matching pass in case the 1st one couldn't find
> >>>>>>>
> >>>>>>> I don't like the second pass.   What problem does it solve?
> >>>>>>
> >>>>>> It addresses the reasons we have various pretty odd (and confusing by
> >>>>>> their mere presence) insn templates which better would never have been
> >>>>>> there. If you have a better suggestion to eliminate those, I'm all ears.
> >>>>>>
> >>>>>> You can also easily see the issues this solves by looking at the
> >>>>>> testsuite changes. Among other things this once again is a matter of
> >>>>>> providing consistent and hence predictable behavior.
> >>>>>
> >>>>> Did you mean the error reporting behavior?  I don't think we should add
> >>>>> a second pass just for it.
> >>>>
> >>>> No. Certain insns simply were not accepted previously (this is actually
> >>>> what finally made me think of a solution here; prior observations
> >>>> weren't severe enough to try to get past your possible opposition which
> >>>> was to be expected based on past discussions). And certain other ones
> >>>> were wrongly accepted.
> >>>
> >>> Please open bug reports for these cases.
> >>
> >> PR gas/29524
> >> PR gas/29525
> >> PR gas/29526
> >>
> >> But really - what's the point of making me waste time on creating bug
> >> reports when fixes are already available?
> >
> > I don't see them as real issues and we shouldn't make assembler
> > more complex because of them.
>
> I sincerely disagree. As said many times - first and foremost the assembler
> should behave _consistently_. People should be able to predict behavior for
> one insn by knowing what the behavior is for sufficiently similar insns,
> without - as is the case twice here - having to further consider anomalies
> resulting from _dissimilar_ insns.

Assembler should be consistent with x86 SDM and the existing usage.
Due to the history/nature of AT&T syntax and x86 instructions, there are
existing inconsistencies.  I don't think we should issue a warning for cmpsd.
It is inconsistent with the 'd' suffix instead of 'l'.  But it is
consistent with SDM.
What I'd like to see in mnemonics:

1. They are as close to SDM as possible.
2. Allow prefix when there is an ambiguity.
3. Intel syntax shouldn't depend on prefixes

BTW, there is one inconsistency:

https://sourceware.org/bugzilla/show_bug.cgi?id=29551

I'd like to resolve.

>
> I therefore also disagree with you having closed some of the entered bugs
> as WONTFIX. I have to admit that I really wonder in how far binutils is an
> open source project if (for x86) you alone take such decisions.
>
> Jan



-- 
H.J.