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

["Hu, Lin1" <lin1.hu@intel.com>]

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Monday, October 23, 2023 4:15 PM
> To: Hu, Lin1 <lin1.hu@intel.com>
> Cc: Lu, Hongjiu <hongjiu.lu@intel.com>; binutils@sourceware.org; Cui, Lili
> <lili.cui@intel.com>
> Subject: Re: [PATCH 5/8] Support APX NDD optimized encoding.
> 
> 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.

Oh, you are right. It seems that CFCMOVcc doesn't support this optimization from the instruction behavior. But CFCMOVcc support doesn't in this round of work. At the moment, I thinks we can use "i.has_nf && i.tm.opcode_modifier.nf" to exclude CFCMOVcc and other NF insns.

> 
> >>>> @@ -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.

OK. Thanks for your idea.

> 
> Jan