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

[Jan Beulich <jbeulich@suse.com>]

On 23.10.2023 09:50, Hu, Lin1 wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: Monday, October 23, 2023 3:24 PM
>>
>> On 23.10.2023 04:57, Hu, Lin1 wrote:
>>
>>> -----Original Message-----
>>> From: Jan Beulich <jbeulich@suse.com>
>>> Sent: Thursday, September 28, 2023 5:30 PM
>>>
>>> On 19.09.2023 17:25, Cui, Lili wrote:
>>>> --- a/gas/config/tc-i386.c
>>>> +++ b/gas/config/tc-i386.c
>>>> @@ -7091,6 +7091,46 @@ check_EgprOperands (const insn_template *t)
>>>>    return 0;
>>>>  }
>>>>
>>>> +/* Optimize APX NDD insns to non-NDD insns.  */
>>>> +
>>>> +static int
>>>
>>> "bool" please when the function merely returns a yes/no indicator.
>>>
>>> * Have modified.
>>>
>>>> +optimize_NDD_to_nonNDD (const insn_template *t) {
>>>> +  if (t->opcode_modifier.vexvvvv
>>>> +      && t->opcode_space == SPACE_EVEXMAP4
>>>> +      && i.reg_operands >= 2
>>>
>>> See the remark near the bottom of the changes to this file: This
>>> condition is likely insufficient, as
>>> - further insns allowing ND may not be treated this way (CCMPscc,
>>>   CTESTscc, and one of the CFCMOVcc forms at the very least),
>>> - {nf} uses will want excluding, as it would be merely a waste of
>>>   time to try to re-match with fewer operands.
>>>
>>> * CCMPSCC and CTESTSCC’s vexvvvv will be false. I think one of the
>> CFCMOVCC forms is same.
>>
>> By "is same" do you mean "fits the optimization pattern here"?
>>
> 
> Because I didn't find any insn that allowing ND, but its vexvvvv is true in CFCMOVcc's table. I'm going to assume that you found it, but I don't see it. I believe its vexvvvv is false, too. So I say it is same as CCMPSCC and CTESTSCC.

CFCMOVcc permits ND and uses EVEX.vvvv in one of its forms. It's unclear
to me whether it can be "optimized", though. In any event, I'd like to
revisit the condition here once this patch comes after all functional
ones, so we (I) have a clear picture of how all the insns are represented
in the opcode table.

>>>> @@ -7562,6 +7602,15 @@ match_template (char mnem_suffix)
>>>>  	     slip through to break.  */
>>>>  	}
>>>>
>>>> +      /* If we can optimize a NDD insn to non-NDD insn, like
>>>> +	 add %r16, %r8, %r8 -> add %r16, %r8, then rematch template.  */
>>>> +      if (optimize_NDD_to_nonNDD (t))
>>>
>>> I don't think such an optimization should be done without any form of -O.
>>>
>>> As to the function name, maybe better optimize_NDD_to_REX2()?
>>>
>>> * Refer to the optimization of VOP, temporarily set to O1 will be optimized.  If
>> we use 32bit register, some instructions will be optimized from NDD to rex or
>> legacy. Like cmovg  0x90909090(%eax),%edx,%edx, imul   %rdx,%rax,%rdx in our
>> test.
>>
>> What you you mean by saying "temporarily"?
> 
> Since we don't have any relevant experience, we'd like to see if you have any opinion on this. If you haven't, users will use O1 to optimize their NDD insns.

This kind of optimization is, aiui, mostly size optimization. Hence first and
foremost -Os ought to trigger it. Whether -O1 should also trigger it is up
for discussing.

Jan