public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* Use cbranch optabs in ifcvt.c
@ 2015-08-24 11:23 Richard Sandiford
  2015-08-24 17:00 ` Jeff Law
  0 siblings, 1 reply; 2+ messages in thread
From: Richard Sandiford @ 2015-08-24 11:23 UTC (permalink / raw)
  To: gcc-patches

Similarly to the patch for cmpstr(n), this patch uses the optabs
interface for cbranchcc4 instead of using HAVE_cbranchcc4 directly.
I've cached the result in a pass-local variable (valid only for
the duration of the pass).

The references to incscc and decscc are dead.  The only reference
to them in the documentation is:

    Some machines can also perform @code{and} or @code{plus} operations on
    condition code values with less instructions than the corresponding
    @samp{cstore@var{mode}4} insn followed by @code{and} or @code{plus}.  On those
    machines, define the appropriate patterns.  Use the names @code{incscc}
    and @code{decscc}, respectively, for the patterns which perform
    @code{plus} or @code{minus} operations on condition code values.  See
    @file{rs6000.md} for some examples.  The GNU Superoptimizer can be used to
    find such instruction sequences on other machines.

which is in tm.texi rather than md.texi.  This seems hopelessly out of
date, not least because rs6000.md has no incscc or decscc patterns.
If the "appropriate patterns" are just combine patterns, perhaps we
should just delete the whole paragraph?

Tested on x86_64-linux-gnu.  OK to install?

Thanks,
Richard

gcc/
	* ifcvt.c (HAVE_incscc, HAVE_decscc, HAVE_cbranchcc4): Delete.
	(have_cbranchcc4): New variable.
	(cc_in_cond, noce_emit_cmove, noce_get_alt_condition)
	(noce_get_condition): Use it instead of HAVE_cbranchcc4.
	(if_convert): Initialize have_cbranchcc4.

diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c
index a46efec..5cf1721 100644
--- a/gcc/ifcvt.c
+++ b/gcc/ifcvt.c
@@ -55,23 +55,12 @@
 #include "shrink-wrap.h"
 #include "ifcvt.h"
 
-#ifndef HAVE_incscc
-#define HAVE_incscc 0
-#endif
-#ifndef HAVE_decscc
-#define HAVE_decscc 0
-#endif
-
 #ifndef MAX_CONDITIONAL_EXECUTE
 #define MAX_CONDITIONAL_EXECUTE \
   (BRANCH_COST (optimize_function_for_speed_p (cfun), false) \
    + 1)
 #endif
 
-#ifndef HAVE_cbranchcc4
-#define HAVE_cbranchcc4 0
-#endif
-
 #define IFCVT_MULTIPLE_DUMPS 1
 
 #define NULL_BLOCK	((basic_block) NULL)
@@ -79,6 +68,9 @@
 /* True if after combine pass.  */
 static bool ifcvt_after_combine;
 
+/* True if the target has the cbranchcc4 optab.  */
+static bool have_cbranchcc4;
+
 /* # of IF-THEN or IF-THEN-ELSE blocks we looked at  */
 static int num_possible_if_blocks;
 
@@ -1014,7 +1006,7 @@ noce_emit_move_insn (rtx x, rtx y)
 static rtx
 cc_in_cond (rtx cond)
 {
-  if (HAVE_cbranchcc4 && cond
+  if (have_cbranchcc4 && cond
       && GET_MODE_CLASS (GET_MODE (XEXP (cond, 0))) == MODE_CC)
     return XEXP (cond, 0);
 
@@ -1557,7 +1549,7 @@ noce_emit_cmove (struct noce_if_info *if_info, rtx x, enum rtx_code code,
   if (! general_operand (cmp_a, GET_MODE (cmp_a))
       || ! general_operand (cmp_b, GET_MODE (cmp_b)))
     {
-      if (!(HAVE_cbranchcc4)
+      if (!have_cbranchcc4
 	  || GET_MODE_CLASS (GET_MODE (cmp_a)) != MODE_CC
 	  || cmp_b != const0_rtx)
 	return NULL_RTX;
@@ -2052,7 +2044,7 @@ noce_get_alt_condition (struct noce_if_info *if_info, rtx target,
     }
 
   cond = canonicalize_condition (if_info->jump, cond, reverse,
-				 earliest, target, HAVE_cbranchcc4, true);
+				 earliest, target, have_cbranchcc4, true);
   if (! cond || ! reg_mentioned_p (target, cond))
     return NULL;
 
@@ -2544,7 +2536,7 @@ noce_get_condition (rtx_insn *jump, rtx_insn **earliest, bool then_else_reversed
   /* Otherwise, fall back on canonicalize_condition to do the dirty
      work of manipulating MODE_CC values and COMPARE rtx codes.  */
   tmp = canonicalize_condition (jump, cond, reverse, earliest,
-				NULL_RTX, HAVE_cbranchcc4, true);
+				NULL_RTX, have_cbranchcc4, true);
 
   /* We don't handle side-effects in the condition, like handling
      REG_INC notes and making sure no duplicate conditions are emitted.  */
@@ -4645,6 +4637,8 @@ if_convert (bool after_combine)
 
   /* Record whether we are after combine pass.  */
   ifcvt_after_combine = after_combine;
+  have_cbranchcc4 = (direct_optab_handler (cbranch_optab, CCmode)
+		     != CODE_FOR_nothing);
   num_possible_if_blocks = 0;
   num_updated_if_blocks = 0;
   num_true_changes = 0;

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Use cbranch optabs in ifcvt.c
  2015-08-24 11:23 Use cbranch optabs in ifcvt.c Richard Sandiford
@ 2015-08-24 17:00 ` Jeff Law
  0 siblings, 0 replies; 2+ messages in thread
From: Jeff Law @ 2015-08-24 17:00 UTC (permalink / raw)
  To: gcc-patches, richard.sandiford

On 08/24/2015 05:20 AM, Richard Sandiford wrote:
> Similarly to the patch for cmpstr(n), this patch uses the optabs
> interface for cbranchcc4 instead of using HAVE_cbranchcc4 directly.
> I've cached the result in a pass-local variable (valid only for
> the duration of the pass).
>
> The references to incscc and decscc are dead.  The only reference
> to them in the documentation is:
>
>      Some machines can also perform @code{and} or @code{plus} operations on
>      condition code values with less instructions than the corresponding
>      @samp{cstore@var{mode}4} insn followed by @code{and} or @code{plus}.  On those
>      machines, define the appropriate patterns.  Use the names @code{incscc}
>      and @code{decscc}, respectively, for the patterns which perform
>      @code{plus} or @code{minus} operations on condition code values.  See
>      @file{rs6000.md} for some examples.  The GNU Superoptimizer can be used to
>      find such instruction sequences on other machines.
>
> which is in tm.texi rather than md.texi.  This seems hopelessly out of
> date, not least because rs6000.md has no incscc or decscc patterns.
> If the "appropriate patterns" are just combine patterns, perhaps we
> should just delete the whole paragraph?
I think the whole paragraph should just go away.  We don't do anything 
with those special patterns anymore.   The PA still defines them, but 
they're just combiner patterns in the end.




>
> Tested on x86_64-linux-gnu.  OK to install?
>
> Thanks,
> Richard
>
> gcc/
> 	* ifcvt.c (HAVE_incscc, HAVE_decscc, HAVE_cbranchcc4): Delete.
> 	(have_cbranchcc4): New variable.
> 	(cc_in_cond, noce_emit_cmove, noce_get_alt_condition)
> 	(noce_get_condition): Use it instead of HAVE_cbranchcc4.
> 	(if_convert): Initialize have_cbranchcc4.
OK.
jeff

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2015-08-24 16:49 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-08-24 11:23 Use cbranch optabs in ifcvt.c Richard Sandiford
2015-08-24 17:00 ` Jeff Law

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).