https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87465
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2018-09-29
Target Milestone|9.0 |8.3
Ever confirmed|0 |1
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |missed-optimization
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Agreed. Note we do have such brute-forcing but only quite limited with
loop_niter_by_eval ().
Note that with -funroll-loops (or -O3) we peel the innermost loop
but then
Not unrolling loop 1: number of branches on hot path in the unrolled sequence
reaches --param max-peel-branches limit.
But I have a simple fix for the testcase...
Index: gcc/tree-ssa-loop-ivcanon.c
===================================================================
--- gcc/tree-ssa-loop-ivcanon.c (revision 264734)
+++ gcc/tree-ssa-loop-ivcanon.c (working copy)
@@ -368,8 +368,8 @@ tree_estimate_loop_size (struct loop *lo
size->non_call_stmts_on_hot_path++;
if (((gimple_code (stmt) == GIMPLE_COND
&& (!constant_after_peeling (gimple_cond_lhs (stmt), stmt,
loop)
- || constant_after_peeling (gimple_cond_rhs (stmt), stmt,
- loop)))
+ || !constant_after_peeling (gimple_cond_rhs (stmt), stmt,
+ loop)))
|| (gimple_code (stmt) == GIMPLE_SWITCH
&& !constant_after_peeling (gimple_switch_index (
as_a <gswitch *> (stmt)),
