This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: [PATCH 1/n] Add conditional compare support


> -----Original Message-----
> From: Richard Henderson [mailto:rth@redhat.com]
> Sent: Friday, November 01, 2013 12:27 AM
> To: Zhenqiang Chen
> Cc: Richard Earnshaw; 'Richard Biener'; GCC Patches
> Subject: Re: [PATCH 1/n] Add conditional compare support
> 
> On 10/31/2013 02:06 AM, Zhenqiang Chen wrote:
> > With two compares, we might swap the order of the two compares to get
> > a valid combination. This is what current ARM does (Please refer
> > arm_select_dominace_cc_mode, cmp_and, cmp_ior, and_scc_scc and
> ior_scc_scc).
> > To improve gen_ccmp_first, we need another function/hook to determine
> > which compare is done first. I will double check ARM backend to avoid hook.
> 
> Hmm.  I hadn't thought of that, and missed that point when looking through
> your previous patches.  I think you should have a third hook for that.  ARM
> will need it, but IA-64 doesn't.

Thanks. I add a new hook. The default function will return -1 if the target does not care about the order.

+DEFHOOK
+(select_ccmp_cmp_order,
+ "For some target (like ARM), the order of two compares is sensitive for\n\
+conditional compare.  cmp0-cmp1 might be an invalid combination.  But when\n\
+swapping the order, cmp1-cmp0 is valid.  The function will return\n\
+  -1: if @code{code1} and @code{code2} are valid combination.\n\
+   1: if @code{code2} and @code{code1} are valid combination.\n\
+   0: both are invalid.",
+ int, (int code1, int code2),
+ default_select_ccmp_cmp_order)
 
> > Hook gen_ccmp_next needs one more parameter to indicate AND/IOR
> since
> > they will generate different instructions.
> 
> True, I forgot about that while writing the hook descriptions.

For gen_ccmp_next, I add another parameter CC_P to indicate the result is used as CC or not. If CC_P is false, the gen_ccmp_next will return a general register. This is for code like

int test (int a, int b)
{
  return a > 0 && b > 0;
}
During expand, there might have no branch at all. So gen_ccmp_next  can not return CC for "a > 0 && b > 0".

+DEFHOOK
+(gen_ccmp_next,
+ "This function emits a conditional comparison within a sequence of\n\
+ conditional comparisons.  The @code{prev} expression is the result of a\n\
+ prior call to @code{gen_ccmp_first} or @code{gen_ccmp_next}.  It may return\n\
+ @code{NULL} if the combination of @code{prev} and this comparison is\n\
+ not supported, otherwise the result must be appropriate for passing to\n\
+ @code{gen_ccmp_next} or @code{cbranch_optab} if @code{cc_p} is true.\n\
+ If @code{cc_p} is false, it returns a general register.  @code{bit_code}\n\
+ is AND or IOR, which is the op on the two compares.",
+ rtx, (rtx prev, int cmp_code, rtx op0, rtx op1, int bit_code, bool cc_p),
+ NULL)

A updated patch is attached.

Thanks!
-Zhenqiang

Attachment: ccmp-hook3.patch
Description: Binary data


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]