On Mon, Jul 24, 2017 at 1:16 PM, Marc Glisse <marc.gli...@inria.fr> wrote: > 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? Yes, it's doesn't matter.
> >> 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. Thanks for elaboration. It's too late for next forwprop pass since we are in between loop optimizations and need the simplified code for niter analysis. Function compute_new_first_bound calls gimple_build several times, it's not likely to replace all gimple_build with gimple_simplify? Also gimple_simplify could return NULL_TREE, in which case I need to call gimple_build_assign again. At last, we don't have interface fold_seq similar to fold_stmt either. CCing Jakub if he found a solution. Thanks. Thanks, bin > > -- > Marc Glisse
