Re: [PATCH] Improve combining of conditionals

[Eric Botcazou <ebotcazou@adacore.com>]

> The patch was successfully tested on {i686, arm, mips}-linux, both GCC
> testsuites and SPEC2000 runs.  For all targets there was no observable code
> difference in SPEC2000 benchmarks, so the example does not trigger very
> often.  Still, it speeds up CoreMark by about 1%.
>
> OK for trunk?

Yes, modulo the following nits:

@@ -4938,11 +4938,13 @@ find_split_point (rtx *loc, rtx insn, bool set_src)
 
    IN_DEST is nonzero if we are processing the SET_DEST of a SET.
 
+   IN_COND is nonzero if we are on top level of the condition.

"...we are at the top level of a condition."


@@ -5221,10 +5225,12 @@ subst (rtx x, rtx from, rtx to, int in_dest, int 
unique_copy)
    expression.
 
    OP0_MODE is the original mode of XEXP (x, 0).  IN_DEST is nonzero
-   if we are inside a SET_DEST.  */
+   if we are inside a SET_DEST.  IN_COND is nonzero if we are on the top level
+   of a condition.  */

Likewise.


@@ -5717,7 +5723,16 @@ combine_simplify_rtx (rtx x, enum machine_mode op0_mode, 
int in_dest)
 	     ZERO_EXTRACT is indeed appropriate, it will be placed back by
 	     the call to make_compound_operation in the SET case.  */
 
-	  if (STORE_FLAG_VALUE == 1
+	  if (in_cond)
+	    /* Don't apply below optimizations if the caller would
+	       prefer a comparison rather than a value.
+	       E.g., for the condition in an IF_THEN_ELSE most targets need
+	       an explicit comparison.  */
+	    {
+	      ;
+	    }

Remove the superfluous parentheses and move the comment to a new paragraph of 
the big comment just above.

No need to retest, just make sure this still compiles, thanks in advance.

-- 
Eric Botcazou