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

[Hu, Lin1]

> -----Original Message-----
> From: Jan Beulich <jbeulich@suse.com>
> Sent: Tuesday, October 24, 2023 2:04 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 24.10.2023 03:40, Hu, Lin1 wrote:
> >> -----Original Message-----
> >> From: Jan Beulich <jbeulich@suse.com>
> >> Sent: Monday, October 23, 2023 4:15 PM
> >>
> >> 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.
> 
> Well, as said before - imo it would be best if the optimization patch came after
> all functional ones.

Yes, I'll release the v3 version of this patch after all functional patches are out.

> 
> Jan