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

[Jan Beulich <jbeulich@suse.com>]

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?

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