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

Andrew Macleod <amacleod at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |amacleod at redhat dot 
com

--- Comment #4 from Andrew Macleod <amacleod at redhat dot com> ---
Created attachment 51935
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51935&action=edit
proposed patch

It gets eliminated/folded by propagation in VRP2 because it shosws one edge as
being executable and the other not:   (from *.169t.vect)

  _35 = offset_13(D) + 65535;
  if (_35 <= 6)
    goto <bb 14>; [10.00%]
  else
    goto <bb 9>; [90.00%]
;;    succ:       9 [90.0% (guessed)]  count:94607391 (estimated locally)
(FALSE_VALUE,EXECUTABLE)
;;                14 [10.0% (guessed)]  count:10511933 (estimated locally)
(TRUE_VALUE)

substitute_and_fold_dom_walker::before_dom_children keys off of:

     if (gimple_code (stmt) == GIMPLE_COND)
        {
          if ((EDGE_SUCC (bb, 0)->flags & EDGE_EXECUTABLE)
              ^ (EDGE_SUCC (bb, 1)->flags & EDGE_EXECUTABLE))

And folds the IF away.

I see inconsistencies in the value of the executable flag.  Im a little
confused, because this code using EDGE_EXECUTABLE is in
substitute_and_fold_dom_walker, and will fold away conditions like this, yet it
does not initialize the domwalker with  REACHABLE_BLOCKS, so non of the edges
are set.   The old VRP use to invoke set_all_edges_as_executable() itself,
ranger is currently only doing it when we run warn_array_bounds_p.

SO my questions are
1) are EDGE_EXECUTABLE flags allowed to be in garbage state outside the
propagation passes?  I think the answer is yes?
2) If this code can always be triggered in substitute_and_fold, should it not
create the dom_walker class with REACHABLE_BLOCKS so that they are in a known
state before any pass triggers them?
3) if that is undesirable for some reason, then I could always set them in
ranger vrp set up, but (2) seems more rational to me.

I've attached a patch which does that... and seems to solve the problem.   Is
this the direction to go?

Reply via email to