Re: readability improvements to i386-opc.tbl

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

On Thu, Nov 16, 2017 at 3:35 AM, Jan Beulich <JBeulich@suse.com> wrote:
>>>> 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.

Remove those No_xSuf should also simplify assembler.

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

I need to take a look at the actual change.


-- 
H.J.