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

[Jan Beulich <jbeulich@suse.com>]

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