[Bug tree-optimization/92862] Suspicious codes in tree-ssa-loop-niter.c and predict.c

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92862

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2019-12-09
                 CC|                            |hubicka at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Feng Xue from comment #0)
> Function loop_only_exit_p() in tree-ssa-loop-niter.c:
> 
>   for (i = 0; i < loop->num_nodes; i++)
>     {
>       for (bsi = gsi_start_bb (body[i]); !gsi_end_p (bsi); gsi_next (&bsi))
> 	if (stmt_can_terminate_bb_p (gsi_stmt (bsi)))
> 	  {
> 	    return true;
> 	  }
>     }
> 
> we should return false, not true?

Indeed...  A patch fixing this is pre-approved (and obvious).

> 
> Function predict_paths_leading_to_edge() in predict.c:
> 
>  FOR_EACH_EDGE (e2, ei, bb->succs)
>     if (e2->dest != e->src && e2->dest != e->dest
> 	&& !unlikely_executed_edge_p (e)
> 	&& !dominated_by_p (CDI_POST_DOMINATORS, e->src, e2->dest))
>       {
> 	has_nonloop_edge = true;
> 	break;
>       }
>  
> "e" is loop invariant, I guess that unlikely_executed_edge_p (e) might be
> unlikely_executed_edge_p (e2), which is more reasonable. And we can find
> similar code in predict_paths_for_bb () that uses the latter.

CCing Honza for the above.