[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 #40 from Andrew Macleod <amacleod at redhat dot com> ---

> There is no problem with adding --params, and those are always better than
> magic numbers.
> 
> Btw, I originally wondered why we don't re-compute zone1_12 because it's
> in the imports of the successor (OK, the empty successors single successor
> block) and expected those to trigger re-computes.

Yeah, I don't like magic number either.  I vaguely recall that it changed the
footprint of something and caused linking issues with something else requiring
complete rebuilds which annoyed some people.. but I  have lost the context.


Recomputes have nothing to do with imports, its all about exports.  Exports
drive the range engine... they are the things that change on exit to block
based on the edge taken.  Imports are things which can affect an export. So in
some iterative/analytical world, if the imports to a block do not change, the
exports will not change either.

Recomputes are about having an export from a block in your definition chain.
This means you are only indirectly related to the export.   If the export
changes, then your value may also change if you can be recalculated using the
export.

This issue is fundamentally about how much effort we make into looking if you
can be recomputed.  Its turns out the underlying engine is more efficient than
I realized, and once we indicate it can be calculated, the calculation itself
is actually linear. 

If we stick to single ssa-names dependencies, then even though the lookup is
currently quadratic, for smallish numbers, its pretty minimal impact.

Most cases I've seen that are of impact seem to be a sequence involving a few
casts.  The current patchset with a depth of 5 catches the vast majority of
things, and is not that expensive.