Re: [PATCH] x86: minor improvements to optimize_imm() (part III)

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

On Mon, Oct 31, 2022 at 3:11 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 28.10.2022 18:03, H.J. Lu wrote:
> > On Fri, Oct 28, 2022 at 5:35 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> Earlier tidying still missed an opportunity: There's no need for the
> >> "anyimm" static variable. Instead of using it in the loop to mask
> >> "allowed" (which is necessary to satisfy operand_type_or()'s assertions)
> >> simply use "mask", requiring it to be calculated first. That way the
> >> post-loop masking by "mask" ahead of the operand_type_all_zero() can be
> >> dropped.
> >>
> >> --- a/gas/config/tc-i386.c
> >> +++ b/gas/config/tc-i386.c
> >> @@ -1906,7 +1906,6 @@ operand_type_xor (i386_operand_type x, i
> >>
> >>  static const i386_operand_type disp16_32 = OPERAND_TYPE_DISP16_32;
> >>  static const i386_operand_type anydisp = OPERAND_TYPE_ANYDISP;
> >> -static const i386_operand_type anyimm = OPERAND_TYPE_ANYIMM;
> >>  static const i386_operand_type regxmm = OPERAND_TYPE_REGXMM;
> >>  static const i386_operand_type imm8 = OPERAND_TYPE_IMM8;
> >>  static const i386_operand_type imm8s = OPERAND_TYPE_IMM8S;
> >> @@ -5812,13 +5811,6 @@ optimize_imm (void)
> >>               const insn_template *t = current_templates->start;
> >>
> >>               operand_type_set (&mask, 0);
> >> -             allowed = t->operand_types[op];
> >> -
> >> -             while (++t < current_templates->end)
> >> -               {
> >> -                 allowed = operand_type_and (allowed, anyimm);
> >> -                 allowed = operand_type_or (allowed, t->operand_types[op]);
> >> -               }
> >>               switch (guess_suffix)
> >>                 {
> >>                 case QWORD_MNEM_SUFFIX:
> >> @@ -5837,7 +5829,14 @@ optimize_imm (void)
> >>                 default:
> >>                   break;
> >>                 }
> >> -             allowed = operand_type_and (mask, allowed);
> >> +
> >> +             allowed = operand_type_and (t->operand_types[op], mask);
> >> +             while (++t < current_templates->end)
> >> +               {
> >> +                 allowed = operand_type_or (allowed, t->operand_types[op]);
> >> +                 allowed = operand_type_and (allowed, mask);
> >
> > mask isn't changed in the loop.  Can the AND operation be moved after
> > the loop?
>
> Initially I thought it could, yes, but it cannot: As said in the
> description the AND-ing "is necessary to satisfy operand_type_or()'s
> assertions".
>
> Jan

OK.

Thanks.

-- 
H.J.