[Bug tree-optimization/106514] [12/13 Regression] ranger slowness in path query

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

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.