Re: [PATCH 7/8] Support APX NDD optimized encoding.

[Jan Beulich <jbeulich@suse.com>]

On 15.11.2023 03:52, Hu, Lin1 wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Tuesday, November 14, 2023 6:51 PM
>>
>> On 14.11.2023 03:28, Hu, Lin1 wrote:
>>> @ -7728,6 +7765,40 @@ match_template (char mnem_suffix)
>>>           i.memshift = memshift;
>>>         }
>>>
>>> +      /* If we can optimize a NDD insn to non-NDD insn, like
>>> +        add %r16, %r8, %r8 -> add %r16, %r8,
>>> +        add  %r8, %r16, %r8 -> add %r16, %r8, then rematch template.
>>> +        Note that the semantics have not been changed.  */
>>> +      if (optimize
>>> +         && !i.no_optimize
>>> +         && i.vec_encoding != vex_encoding_evex
>>> +         && t + 1 < current_templates->end
>>> +         && !t[1].opcode_modifier.evex)
>>> +       {
>>> +         unsigned int readonly_var = convert_NDD_to_REX2 (t);
>>> +         if (readonly_var != ~0)
>>> +           {
>>> +             if (!check_EgprOperands (t + 1))
>>> +               {
>>> +                 specific_error = progress (internal_error);
>>> +                 continue;
>>> +               }
>>> +             ++i.operands;
>>> +             ++i.reg_operands;
>>
>> DYM decrement rather than increment for these? We're trying to go from
>> 3 to 2 operands, after all.
>>
> 
> Here's a backtrace to considering for possible other opcode_space (0f38,...) instructions that can't accept the r16+ register, but can accept other rex registers or the normal. I decrement i.operands and i.reg_operands in convert_NDD_to_REX2. If the legacy or rex version of the insn can't support rex2 registers, I won't optimize it. So I need to increment these.

Okay, I need to see the full patch for this. Incrementing to undo earlier
decrementing still looks suspicious to me (for now).

>>> +
>>> +             if (readonly_var == 1)
>>> +               swap_2_operands (0, 1);
>>> +           }
>>> +       }
>>>
>>> convert_NDD_to_REX2 return readonly_var now. check_EgprOperands aims
>> to exclude some insns like adcx and adox. Because their opcode_space is legacy-
>> map2 can't support rex2.
>>
>> Good. Looking forward to seeing the full change.
>>
> 
> For some insns like adcx and adox, I'd like to add some details. check_EgprOperands only used to exclude some situation that these insns with gpr32 registers. If we think about optimization in terms of encoding length. Is it safe to assume that some insn with prefixes 66, f2, f3 and their opcode_space isn't legacy-map0 or legacy-map1 won't reduce the length of the code even if they are optimized?

Well, no, not always. See my other reply regarding 32-bit ADCX/ADOX.

> If yes, I think the code can be simplified like:
> 
>        /* If we can optimize a NDD insn to non-NDD insn, like
>           add %r16, %r8, %r8 -> add %r16, %r8,
>            add  %r8, %r16, %r8 -> add %r16, %r8, then rematch template.
>            Note that the semantics have not been changed.  */
>         if (optimize
>             && !i.no_optimize
>             && i.vec_encoding != vex_encoding_evex
>             && t + 1 < current_templates->end
>             && !t[1].opcode_modifier.evex
>             && convert_NDD_to_REX2 (t))
>           {
>             specific_error = progress (internal_error);
>             continue;
>           }  
> 
> For those instructions that don't need to be optimized, like adcx and adox we just don't swap the order, so we don't need check_EgprOperands and backtrack, and convert_NDD_to_REX2 has the same return value as before.
> 
> PS. So shouldn't the name of the function be convert_NDD_to_legacy.

Perhaps yes, if the result can also be non-REX2 encodings.

Jan