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.
