Thanks for the comments. All comments are accepted and the updated patch is attached.
-Zhenqiang > -----Original Message----- > From: Richard Henderson [mailto:r...@redhat.com] > Sent: Saturday, October 11, 2014 11:00 PM > To: Zhenqiang Chen; gcc-patches@gcc.gnu.org > Subject: Re: [Ping] [PATCH, 1/10] two hooks for conditional compare (ccmp) > > On 09/22/2014 11:43 PM, Zhenqiang Chen wrote: > > > > +@cindex @code{ccmp} instruction pattern @item @samp{ccmp} > Conditional > > +compare instruction. Operand 2 and 5 are RTLs which perform two > > +comparisons. Operand 1 is AND or IOR, which operates on the result > > +of operand 2 and 5. > > +It uses recursive method to support more than two compares. e.g. > > + > > + CC0 = CMP (a, b); > > + CC1 = CCMP (NE (CC0, 0), CMP (e, f)); ... > > + CCn = CCMP (NE (CCn-1, 0), CMP (...)); > > + > > +Two target hooks are used to generate conditional compares. > > +GEN_CCMP_FISRT is used to generate the first CMP. And > GEN_CCMP_NEXT > > +is used to generate the following CCMPs. Operand 1 is AND or IOR. > > +Operand 3 is the result of GEN_CCMP_FISRT or a previous > GEN_CCMP_NEXT. Operand 2 is NE. > > +Operand 4, 5 and 6 is another compare expression. > > + > > +A typical CCMP pattern looks like > > + > > +@smallexample > > +(define_insn "*ccmp_and_ior" > > + [(set (match_operand 0 "dominant_cc_register" "") > > + (compare > > + (match_operator 1 > > + (match_operator 2 "comparison_operator" > > + [(match_operand 3 "dominant_cc_register") > > + (const_int 0)]) > > + (match_operator 4 "comparison_operator" > > + [(match_operand 5 "register_operand") > > + (match_operand 6 "compare_operand"])) > > + (const_int 0)))] > > + "" > > + "@dots{}") > > +@end smallexample > > + > > This whole section should be removed. You do not have a named ccmp > pattern. > Even your example below is an *unnamed pattern. This is an > implementation detail of the aarch64 backend. > > Named patterns are used when that is the interface the middle-end uses to > emit code. But you're not using named patterns, you're using: > > > > > +@deftypefn {Target Hook} rtx TARGET_GEN_CCMP_FIRST (int > @var{code}, > > +rtx @var{op0}, rtx @var{op1}) This function emits a comparison insn > > +for the first of a sequence of conditional comparisions. It returns > > +a comparison expression appropriate for passing to > @code{gen_ccmp_next} or to @code{cbranch_optab}. > > + @code{unsignedp} is used when converting @code{op0} and > @code{op1}'s mode. > > +@end deftypefn > > + > > +@deftypefn {Target Hook} rtx TARGET_GEN_CCMP_NEXT (rtx @var{prev}, > > +int @var{cmp_code}, rtx @var{op0}, rtx @var{op1}, int @var{bit_code}) > > +This function emits a conditional comparison within a sequence of > > +conditional comparisons. The @code{prev} expression is the result of > > +a prior call to @code{gen_ccmp_first} or @code{gen_ccmp_next}. It > > +may return @code{NULL} if the combination of @code{prev} and this > > +comparison is not supported, otherwise the result must be > > +appropriate for passing to @code{gen_ccmp_next} or > @code{cbranch_optab}. @code{bit_code} is AND or IOR, which is the op on > the two compares. > > +@end deftypefn > > Every place above where you refer to the arguments of the function should > use @var; you're using @code for most of them. Use @code{AND} and > @code{IOR}. > > > r~
1-hooks.patch
Description: Binary data
