Re: readability improvements to i386-opc.tbl

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

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?
2. If yes, will your change 2) help it?


-- 
H.J.