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

[Jan Beulich]

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.

>> 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.

... here will continue to be the case with those later changes.

Jan