This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] x86: imply all No_*Suf when none is set in a template


On Mon, Nov 18, 2019 at 5:10 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 15.11.2019 19:05,  H.J. Lu  wrote:
> > On Fri, Nov 15, 2019 at 12:35 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 14.11.2019 20:26, H.J. Lu wrote:
> >>> On Thu, Nov 14, 2019 at 12:51 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>
> >>>> Since no template would ever allow for none of them to be set, reduce
> >>>> table size and improve readability and hence maintainability by implying
> >>>> all of them to be set when a template specifies none.
> >>>>
> >>>> opcodes/
> >>>> 2019-11-XX  Jan Beulich  <jbeulich@suse.com>
> >>>>
> >>>>         * i386-gen.c (process_i386_opcode_modifier): Widen scope of
> >>>>         bwlq_suf. New local variable other_suf. Emit warning when all
> >>>>         No_*Suf are set. Set all No_*Suf when none are set.
> >>>>         * i386-opc.tbl: Drop No_bSuf, No_wSuf, No_lSuf, No_sSuf,
> >>>>         No_qSuf, and No_ldSuf when they're all specified at the same
> >>>>         time.
> >>>
> >>> I don't think it may the table more readable.   Why not simply add
> >>>
> >>> #define  No_Suf  No_bSuf|No_wSuf|No_lSuf|No_sSuf|No_qSuf|No_ldSuf
> >>>
> >>> and use it?
> >>
> >> Because this would require yet another global change once we switch
> >> to positive identification of the permitted suffixes (which should
> >> have been done from the beginning imo). Since the set of suffixes
> >> that can go together is pretty limited (i.e. a fair subset of the
> >> combinations currently possible to specify do never occur), my plan
> >> is to switch to an enumeration here, containing enumerators like
> >> bwlqSuf or wlqSuf.
> >
> > Replace or remove No_Suf should be very easy.
>
> "easy" is not a category of my thinking here. It's the huge amount
> of code churn and the resulting unless-ness of e.g. "git blame" that
> I'd like to avoid. Dropping the code again that this patch adds to
> i386-gen.c is also "easy" enough.
>

I don't think "git blame" is an issue here.  No_Suf makes clear
what exactly happens.


-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]