[Bug tree-optimization/109154] [13 regression] jump threading de-optimizes nested floating point comparisons

["amacleod at redhat dot com" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #32 from Andrew Macleod <amacleod at redhat dot com> ---

The issues is here is pruning to avoid significant time growth.

  _1 = (float) l_11(D); 
  _2 = _1 < 0.0;
  zone1_12 = (int) _2;
  if (_1 < 0.0)
    goto <bb 3>; [INV]

_1 is an export from the block. In theory if there was a proper range-op entry
for a cast from float to int l_11 could also be an export.

We can recompute anything which directly uses an export from the block. _2 uses
_1 so we can recompute _2.    We currently only support one level of
recomputation because recognition and computation grows between quadratically
and expoential based on the number of recomputations required, and
indentifying/evaluating the levels of indirection...

zone1_12 does not directly use an export, so GORI does not see it as something
which it can evaluate. To evaluate it, we have to see that _2 is recomputable,
reconmpute it, then recompute zone1_12.

This could in theory be an arbitrarily long range, and for performance reasons,
we limited it to 1 up until this point.

Note that is we had used _2:
if (_2 != 0)
   goto <bb 3>
then _2 would be a export, and zone1_12 would be a recomputation and have the
approriate value.

I have plans to eventually rejig GORI to cache outgoing ranges on edges.  This
would allow us to recompute chains without the quadratic growth and we would
have all the recomputations we want, but at this point, we are only doing one
level

We could in theory expand it to look at 2 levels if its a single operand...
which will help with some of these cases where there are casts, and keep the
performance degradation from being too bad.   I'm sure there will be cases
where a third would be handy :-P