> I see you have objected and indicated the additional cost. Have you
> quantified how much more expensive the pass is?
No, but use-def chains are known to be slow because DF is slow, see e.g. the
comment located a few lines below the call to try_merge_compare:
/* ??? This is one point at which one could argue that DF_REF_CHAIN would
be useful, but it is thought to be too heavy-weight a solution here. */
Note that the patch breaks e.g. the Visium port, because the pass now sends
all kind of junk RTXes to the select_cc_mode target hook, which was written to
be in exact keeping with the arithmetic patterns of the MD file. I'm going to
fix the breakage of course, but this shows that the patch burns a large amount
of cycles for targets like Visium for no benefit.
Index: config/visium/visium.c
===================================================================
--- config/visium/visium.c (revision 253767)
+++ config/visium/visium.c (working copy)
@@ -2938,12 +2938,6 @@ visium_select_cc_mode (enum rtx_code cod
/* This is a btst, the result is in C instead of Z. */
return CCCmode;
- case CONST_INT:
- /* This is a degenerate case, typically an uninitialized variable. */
- gcc_assert (op0 == constm1_rtx);
-
- /* ... fall through ... */
-
case REG:
case AND:
case IOR:
@@ -2953,6 +2947,7 @@ visium_select_cc_mode (enum rtx_code cod
case LSHIFTRT:
case TRUNCATE:
case SIGN_EXTEND:
+ case ZERO_EXTEND:
/* Pretend that the flags are set as for a COMPARE with zero.
That's mostly true, except for the 2 right shift insns that
will set the C flag. But the C flag is relevant only for
@@ -2960,6 +2955,16 @@ visium_select_cc_mode (enum rtx_code cod
when applied to a comparison with zero. */
return CCmode;
+ /* ??? Cater to the junk RTXes sent by try_merge_compare. */
+ case ASM_OPERANDS:
+ case CALL:
+ case CONST_INT:
+ case LO_SUM:
+ case HIGH:
+ case MEM:
+ case UNSPEC:
+ return CCmode;
+
default:
gcc_unreachable ();
--
Eric Botcazou
