readability improvements to i386-opc.tbl

[Jan Beulich]

>>> On 16.11.17 at 00:14, <hjl.tools@gmail.com> wrote:
> On Wed, Nov 15, 2017 at 5:55 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>> On 15.11.17 at 14:22, <hjl.tools@gmail.com> wrote:
>>> On Wed, Nov 15, 2017 at 5:10 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>>> On 15.11.17 at 13:43, <hjl.tools@gmail.com> wrote:
>>>>> On Wed, Nov 15, 2017 at 1:33 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>>>> H.J.,
>>>>>>
>>>>>> for a while I've been thinking about how to shrink some of the overly
>>>>>> long lines in that file, as that's imo severely hampering readability
>>>>>> (and hence maintainability). There are two pretty simple
>>>>>> adjustments I'd like to propose as at least a first step, but which I
>>>>>> wouldn't want to carry out without some prior agreement (as the
>>>>>> resulting patches would obviously be huge):
>>>>>>
>>>>>> 1) BaseIndex implies Disp{8,16,32,32S} (with a few MPX insn
>>>>>> exceptions, which aren't necessary as 16-bit addressing not being
>>>>>> legal for them is being dealt with in tc-i386.c explicitly anyway, in
>>>>>> md_assemble()). i386-gen could easily set those implied bits.
>>>>>>
>>>>>> 2) Many instructions allow no suffixes at all (in particular most of
>>>>>> the myriad of SIMD ones). Many other instructions allow just a
>>>>>> single suffix. I'd like to propose No_Suf to accompany No_*Suf
>>>>>> and {b,w,l,s,q,ld}Suf as the inverse of No_*Suf, to be used when
>>>>>> the list of permitted suffixes is shorter than the list of forbidden
>>>>>> ones. Again this could be dealt with in i386-gen relatively easily.
>>>>>>
>>>>>>
>>>>>
>>>>> They sound good.  Can you take a look at
>>>>>
>>>>> https://sourceware.org/bugzilla/show_bug.cgi?id=20320 
>>>>>
>>>>> as the first step?
>>>>
>>>> I think I had looked at precisely that a few years back, finding a few
>>>> cases where there was no full equivalence. In any event the main
>>>> obstacle is the dual purpose use of the 'l' suffix for integer and FPU
>>>> insns. The other immediately obvious issue is with movzx (where
>>>> the suffix describes the destination operand size, but Byte refers
>>>> to the source operand).
>>>
>>> Can we replace these specific cases with something else?
>>
>> Not sure yet; this would certainly go beyond the mostly mechanical
>> work I was intending to do right away. But I may still consider doing
>> so in favor of 2) above, but likely after having done 1) (if that works
>> out in the first place).
>>
> 
> There 2 questions:
> 
> 1. Can PR 20320 be fixed or improved?

As said - possibly. It'll need careful evaluation of the number of
exceptions, and then weighing of whether special casing the
respective cases in tc-i386.c is a price worthwhile to pay for the
simplification of the table.

> 2. If yes, will your change 2) help it?

I don't think so, except for maybe reducing the overall size of
the patch which would result.

Jan