[Bug tree-optimization/103721] [12 regression] wrong code generated for loop with conditional since r12-4790-g4b3a325f07acebf4

["aldyh at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #6 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
Please bear with me, as I'm coming up to speed, and my head hurts from all
these equivalences.

The problem seems to be what Jeff mentioned in comment #4.

We think _5 == _6, which makes the conditional in BB9 always false.  This
allows us to thread 8->9->7:

  <bb 9> [local count: 1073741824]:
  # searchVolume_5 = PHI <searchVolume_11(8), world_7(D)(2)>
  # currentVolume_6 = PHI <currentVolume_8(8), 0(2)>
  _2 = searchVolume_5 != currentVolume_6;
  _3 = searchVolume_5 != 0;
  _4 = _2 & _3;
  if (_4 != 0)
    goto <bb 3>; [89.00%]
  else
    goto <bb 7>; [11.00%]

With --param=threader-debug=all we can see the threader registering the path:

  [1] Registering jump thread: (8, 9) incoming edge;  (9, 7) nocopy; 

The bits immediately preceding it are the solver in action for the proposed
path.  Of particular interest is:

path_range_query: compute_ranges for path: 8->9
 Registering value_relation (currentVolume_8 == searchVolume_5) (bb8) at
currentVolume_8 = PHI <searchVolume_5(4), searchVolume_5(3)>
range_defined_in_block (BB8) for currentVolume_8 is int [-INF, -1][1, +INF]
  from bb9: Registering killing_def (path_oracle) searchVolume_5
 Registering value_relation (path_oracle) (searchVolume_11 == searchVolume_5)
(bb8)
  from bb9: Registering killing_def (path_oracle) currentVolume_6
 Registering value_relation (path_oracle) (currentVolume_8 == currentVolume_6)
(bb8)
range_defined_in_block (BB9) for searchVolume_5 is int [0, 1]
range_defined_in_block (BB9) for currentVolume_6 is int [-INF, -1][1, +INF]

path_oracle:
Equivalence set : [searchVolume_5, currentVolume_6, currentVolume_8]
Equivalence set : [currentVolume_6]
Equivalence set : [searchVolume_5, searchVolume_11]
Equivalence set : [searchVolume_5]

Notice the entry at the top of the path_oracle equivalence queue:

Equivalence set : [searchVolume_5, currentVolume_6, currentVolume_8]

The sequence of events that got us here is the following:

1. When calculating the PHIs for the path, we start at BB8, which triggers a
global ranger's range_of_expr.  We do this, to see if there's anything the
global ranger knows on entry to the path.  This in turn registers an equiv for
_8 == _5 in the *root* oracle (not the path specific one):

 Registering value_relation (currentVolume_8 == searchVolume_5) (bb8) at
currentVolume_8 = PHI <searchVolume_5(4), searchVolume_5(3)>

2. Then in BB9 we set up the following path specific equiv:

 Registering value_relation (path_oracle) (currentVolume_8 == currentVolume_6)
(bb8)

Since the root oracle has _8 == _5, this means we "know" that _8 == _6 == _5 in
the path.

Shit rolls downhill from here.