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

H.J. Lu hjl.tools@gmail.com
Fri Aug 26 18:46:25 GMT 2022


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.

> In any event, I'll be shortly submitting v2 of the series addressing
> these.
>
> >>>> Further this sets the stage for the subsequent two changes, which I
> >>>> don't think are easily possible without this 2nd pass.
> >>>
> >>> Does it indicate that the second pass is used quite often?
> >>
> >> No, what I did say ...
> >>
> >>>> And finally you've likely spotted that this is actually a reduction in
> >>>> code size, first and foremost because the odd maybe_adjust_templates()
> >>>> can now go away. Plus I think you realize that the 2nd pass wouldn't
> >>>> be engaged in many cases - it requires a template match failure in the
> >>>> 1st pass, after all, which isn't going to happen very often.
> >
> > There is a fixed cost to prepare for the second pass.
>
> A very limited one (I suppose there are enough other things which are
> more of an overhead). Plus part of the preparation happens only when
> the first pass didn't find any match.
>
> Jan



-- 
H.J.


More information about the Binutils mailing list