https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106514
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
For the testcase m_imports is so big because we have
...
<bb 1198> [local count: 1073741824]:
# c_1198 = PHI <c_1197(1196), c_2400(1197)>
_599 = MEM[(unsigned int *)b_1201(D) + 2792B];
d_2401 = _599 + d_2399;
if (d_2399 > d_2401)
goto <bb 1199>; [50.00%]
else
goto <bb 1200>; [50.00%]
<bb 1199> [local count: 536870913]:
c_2402 = c_1198 + 1;
<bb 1200> [local count: 1073741824]:
# c_1199 = PHI <c_1198(1198), c_2402(1199)>
_600 = MEM[(unsigned int *)b_1201(D) + 2796B];
d_2403 = _600 + d_2401;
if (d_2401 > d_2403)
goto <bb 1201>; [50.00%]
else
goto <bb 1202>; [50.00%]
so when back_threader::find_paths does ->compute_imports (.., bb 1200) we
walk up the whole d_2403 definition chain unbound (for PHIs we restrict
to edges on the path which is empty). I realize that there's no good way
to pick up extra imports on the fly cheaply - we could handle it when
we prune local defs from the imports at which point we could add operands
but it's not clear to me that will be a good trade-off. In fact
pruning imports looks suspicious as the final path-range query will
be limited there? Likewise for any import we add via PHI-translation
we fail to add local def operands - we're only getting those from the
initial import compute which basically picks those from blocks dominating
the exit but no others.
I will experiment with re-wiring this.
