On 16/07/15 19:13, Segher Boessenkool wrote:
On Thu, Jul 16, 2015 at 04:25:14PM +0100, Kyrill Tkachov wrote:
Hi all,
This is an attempt to solve the problem in the thread starting at
https://gcc.gnu.org/ml/gcc-patches/2015-07/msg01010.html
in a generic way after some pointers from Segher and Andrew.
The problem I got was that combine_simplify_rtx was trying to
do some special handling of unary operations applied to if_then_else
but ended up exiting early due to:
enum rtx_code cond_code = simplify_comparison (NE, &cond, &cop1);
if (cond_code == NE && COMPARISON_P (cond))
return x;
I tried removing that bug that led to regressions in SPEC2006.
The solution that worked for me led to two patches.
In this first patch we add a simplification step to the rtx before trying
any substitutions.
diff --git a/gcc/combine.c b/gcc/combine.c
index 574f874..40d2231 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -5510,6 +5510,17 @@ combine_simplify_rtx (rtx x, machine_mode op0_mode, int
in_dest,
{
rtx cond, true_rtx, false_rtx;
+ /* If some simplification is possible from the start, try it now. */
+ temp = simplify_rtx (x);
+
+ if (temp)
+ {
+ x = temp;
+ code = GET_CODE (x);
+ mode = GET_MODE (x);
+ op0_mode = VOIDmode;
+ }
+
cond = if_then_else_cond (x, &true_rtx, &false_rtx);
if (cond != 0
/* If everything is a comparison, what we have is highly unlikely
If you always want to simplify first, does it work to move this whole big
block behind the simplify just following it? Or do you want to simplify
after the transform as well?
You mean move this hunk outside the "if (BINARY_P (x)...)" block it's in?
I think it would work, but I'm not sure if it would affect other cases.
I was also conscious that simplify_rtx might not be a cheap function to call
so frequently (or is it? I didn't profile it), so I tried to avoid calling
it unless I need for the transformation in question here.
Kyrill
Segher
