https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79460
--- Comment #11 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 14 Feb 2017, amker at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79460 > > --- Comment #10 from amker at gcc dot gnu.org --- > (In reply to Jakub Jelinek from comment #9) > > (In reply to rguent...@suse.de from comment #8) > > > On Tue, 14 Feb 2017, jakub at gcc dot gnu.org wrote: > > > > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79460 > > > > > > > > --- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > > > > Shouldn't it (both in the vectorizer and in scev) be dependent not just > > > > on > > > > flag_fp_contract_mode but also on some -ffast-math subflag? Doing > > > > several > > > > additions can e.g. raise different exceptions and have different > > > > roundings from > > > > doing it as just one multiply. > > > > > > Maybe, but I don't see which (apart from flag_unsafe_math_optimizations > > > of course but we'd want to get rid of that...). reassoc uses > > > flag_unsafe_math_optimizations (and does this for SCALAR_FLOAT_TYPE_P > > > only). The docs only mention FMA for fp-contract... > > > > fp-contract is I believe only about whether you are allowed to transform x = > > a + b * c; into a FMA or not (or similar expressions), so I think isn't even > > related to this. Even if we want to get rid of > > flag_unsafe_math_optimizations eventually, it is better to use that if we > > don't know what exactly rather than emit wrong-code with -fno-fast-math, > > we'll have to eventually add some new flags or figure it out. > > I also think we need flag_unsafe_math_optimizations or similar on this, this > is > risky transformation and we may put iterative numerical algorithms in danger. And here's that unroll heuristic patch (cleaned up a bit), it makes us consider all operations on constants (where SCEV can compute an evolution) as constant (and actually also folds them in the poor-mans cprop code). Only works up to 16 iterations of course (thus for the testcase for an upper bound of 16*4). Kind of unrelated to this PR of course. Index: gcc/tree-ssa-loop-ivcanon.c =================================================================== --- gcc/tree-ssa-loop-ivcanon.c (revision 245417) +++ gcc/tree-ssa-loop-ivcanon.c (working copy) @@ -157,8 +157,6 @@ struct loop_size static bool constant_after_peeling (tree op, gimple *stmt, struct loop *loop) { - affine_iv iv; - if (is_gimple_min_invariant (op)) return true; @@ -189,11 +187,9 @@ constant_after_peeling (tree op, gimple } /* Induction variables are constants. */ - if (!simple_iv (loop, loop_containing_stmt (stmt), op, &iv, false)) - return false; - if (!is_gimple_min_invariant (iv.base)) - return false; - if (!is_gimple_min_invariant (iv.step)) + tree ev = analyze_scalar_evolution (loop, op); + if (chrec_contains_undetermined (ev) + || chrec_contains_symbols (ev)) return false; return true; } @@ -1259,7 +1255,7 @@ propagate_constants_for_unrolling (basic if (! SSA_NAME_OCCURS_IN_ABNORMAL_PHI (result) && gimple_phi_num_args (phi) == 1 - && TREE_CODE (arg) == INTEGER_CST) + && CONSTANT_CLASS_P (arg)) { replace_uses_by (result, arg); gsi_remove (&gsi, true); @@ -1276,7 +1272,7 @@ propagate_constants_for_unrolling (basic tree lhs; if (is_gimple_assign (stmt) - && gimple_assign_rhs_code (stmt) == INTEGER_CST + && TREE_CODE_CLASS (gimple_assign_rhs_code (stmt)) == tcc_constant && (lhs = gimple_assign_lhs (stmt), TREE_CODE (lhs) == SSA_NAME) && !SSA_NAME_OCCURS_IN_ABNORMAL_PHI (lhs)) {
