[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 #34 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Jakub Jelinek from comment #33)
> (In reply to Andrew Macleod from comment #32)
> > We could in theory expand it to look at 2 levels if its a single operand...
> 
> Yeah, that would help here and could be worth it.
> 
> > 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
> 
> And/or, could we go from seeing zone1_12 in an PHI arg and in that case walk
> a level or two or three to see if it is dependent on an SSA_NAME known to
> have specific range on the edge and if so, do those range queries using that
> range?

well, its knowing it has a specific ranges that is the not-cheap part. For
every one we find a useful range, therea re likely many queries that do not
fina anything useful.  and every level of indirection adds to that.

So we know zone1_12 uses _2, we can see that it is a recomputable value, but
without outgoing edge values cached, we have to actually calculate it.   Until
we calculate it, we dont know that its going to help us.. we just know it *can*
be recomputed, not that its useful.

Even if we limited it to just PHI arguments (which specializing is not easy
btw), that means every PHI argument could have additional 2nd level checks and
recomputations, many of which are not useful.

I will poke at whether its possible to cheaply handle a second (or third) level
for single dependency defs.