Re: [PATCH][v3] Support APX NDD optimized encoding.

[Jan Beulich <jbeulich@suse.com>]

On 20.11.2023 04:28, Hu, Lin1 wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Friday, November 17, 2023 5:48 PM
>>
>> On 17.11.2023 08:24, Hu, Lin1 wrote:
>>>> -----Original Message-----
>>>> From: Jan Beulich <jbeulich@suse.com>
>>>> Sent: Wednesday, November 15, 2023 5:35 PM
>>>>
>>>> On 15.11.2023 03:59, Hu, Lin1 wrote:
>>>>> --- a/gas/config/tc-i386.c
>>>>> +++ b/gas/config/tc-i386.c
>>>>> @@ -7208,6 +7208,43 @@ check_EgprOperands (const insn_template *t)
>>>>>    return 0;
>>>>>  }
>>>>>
>>>>> +/* Optimize APX NDD insns to legacy insns.  */ static bool
>>>>> +convert_NDD_to_REX2 (const insn_template *t) {
>>>>> +  if (t->opcode_modifier.vexvvvv == VexVVVV_DST
>>>>> +      && t->opcode_space == SPACE_EVEXMAP4
>>>>> +      && !i.has_nf
>>>>> +      && i.reg_operands >= 2)
>>>>> +    {
>>>>> +      unsigned int readonly_var = ~0;
>>>>> +      unsigned int dest = i.operands - 1;
>>>>> +      unsigned int src1 = i.operands - 2;
>>>>> +      unsigned int src2 = (i.operands > 3) ? i.operands - 3 : 0;
>>>>> +
>>>>> +      if (i.types[src1].bitfield.class == Reg
>>>>> +	  && i.op[src1].regs == i.op[dest].regs)
>>>>> +	readonly_var = src2;
>>>>> +      /* adcx, adox and imul can't support to swap the source operands.
>> */
>>>>> +      else if (i.types[src2].bitfield.class == Reg
>>>>> +	       && i.op[src2].regs == i.op[dest].regs
>>>>> +	       && optimize > 1
>>>>> +	       && t->opcode_modifier.commutative)
>>>>
>>>> Comment and code still aren't in line: "support to swap the source
>>>> operands"
>>>> really is the D attribute in the opcode table, whereas
>>>> t->opcode_modifier.commutative is related to the C attribute (and all
>>>> t->three
>>>> insns named really are commutative). It looks to me that the code is
>>>> correct, so it would then be the comment that may need updating. But
>>>> it may also be better to additionally check .d here (making the code
>>>> robust against C being added to the truly commutative yet not eligible to
>> be optimized insns).
>>>> In which case the comment might say "adcx, adox, and imul, while
>>>> commutative, don't support to swap the source operands".
>>>>
>>>
>>> I think we don't need to worry about it for now, because we've constrained
>> the function with vexvvvvvvdest, and these instructions must be NDD
>> instructions. And adcx, adox and imul don't have D attribute.
>>
>> Right, and I thought to leverage this. IOW ...
>>
>>> If I add check .d here, I will need to exclude them.
>>
>> ... I don't think I understand this.
>>
> 
> I mean this place is to check if we can optimize something like "adcx %eax, %ebx, %eax -> adcx %ebx, %eax".  Adcx doesn't support D attribute, if we want to add a constraint t->opcode_modifier.d. The constraints should be && (t->opcode_modifier.d || t->mnem_off == MN_adcx) && t->opcode_modifier.commutative, because, adcx doesn't support D attribute. If we doesn't exclude it, it will be stopped by t->opcode_modifier.d.

Just to clarify again: My main issue is with comment and code not being
in sync. Once that's sorted, maybe it'll become clear why you need to
check C rather than D, when at the same time you avoid to add C for
those insns which don't support D anyway (and would hence be
recognizable either way).

>>> +/* Optimize APX NDD insns to legacy insns.  */ static unsigned int
>>> +convert_NDD_to_legacy (const insn_template *t) {
>>> +  unsigned int readonly_var = ~0;
>>
>> One issue I continue to have is the name of this variable. Good names help
>> understanding what code is doing. And in 3-operand NDD insns there are
>> uniformly 2 operands which are only read.
> 
> Maybe I should change the variable to be called readonly_reg_pos.

What would this change? There are, as before, potentially two operands
which are input only (i.e. readonly). What property of the operand is it
that you're after? Answering that will tell what a reasonable name for
the variable is.

>>> +       {
>>> +         unsigned int readonly_var = convert_NDD_to_legacy (t);
>>> +         size_match = true;
>>> +
>>> +         if (readonly_var != (unsigned int) ~0)
>>> +           {
>>> +             for (j = 0; j < i.operands - 2; j++)
>>> +               {
>>> +                 check_register = j;
>>> +                 if (t->opcode_modifier.d)
>>> +                   check_register ^= 1;
>>> +                 overlap0 = operand_type_and (i.types[check_register],
>>> +                                              t[1].operand_types[check_register]);
>>> +                 if (!operand_type_match (overlap0, i.types[check_register]))
>>> +                   size_match = false;
>>> +               }
>>
>> I'm afraid that without a comment I don't understand what this is about.
>>
> 
> I want to make sure that the two neighboring templates have the same input. I tried base_code but it misses some special cases, so I want to start with the first parameter (ATT), like shld Imm8 and shld shiftCount. But some insns with .d. So I need to check if the first operand can match the second type.  Seems like it looks like NDD can simply match that way now.

Okay, something along these lines will want saying in a comment then. That's
not to say though that I'm convinced this is needed. With all these code
fragments and out-of-order patches that were sent I'm really looking forward
to getting a consistent, properly ordered series again, such that I can
actually see how things fit together.

Jan