On Mon, 24 Jul 2017, Bin.Cheng wrote:
For _123, we have/* (A +- CST1) +- CST2 -> A + CST3 or /* Associate (p +p off1) +p off2 as (p +p (off1 + off2)). */ For _115, we have /* min (a, a + CST) -> a where CST is positive. */ /* min (a, a + CST) -> a + CST where CST is negative. */ (simplify (min:c @0 (plus@2 @0 INTEGER_CST@1)) (if (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (@0))) (if (tree_int_cst_sgn (@1) > 0) @0 @2))) What is the type of all those SSA_NAMEs?Hi, From the debugging process, there are two issues preventing "(A +- CST1) +- CST2 -> A + CST3" from being applied: A) before we reach this pattern, there is pattern: /* A - B -> A + (-B) if B is easily negatable. */ (simplify (minus @0 negate_expr_p@1) (if (!FIXED_POINT_TYPE_P (type)) (plus @0 (negate @1)))) which is matched and returned in gimple_simplify_MINUS_EXPR. So does pattern order matter here?
That shouldn't be a problem, normally we always try to resimplify the result of the simplification, and the transformation should handle x+1+-1 just as well as x+1-1. Is that not happening?
B) When folding "_124 - 1" on the basis of existing stmts sequence like "_124 = _197 + 1;". The corresponding gimple-match.c code is like:
[...]
But since definition of _197 isn't in current stmt sequence, call "o31 = do_valueize (valueize, o31)" will return NULL. As a result, it's not matched.
Ah, yes, that problem... Jakub was having a very similar issue a few weeks ago, don't know if he found a solution. You could call gimple_simplify directly with a different valueization function if that's safe. Normally the simplification would wait until the next forwprop pass. -- Marc Glisse
