https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #9 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Richard Biener from comment #7)
> (In reply to Richard Biener from comment #6)
> > ah, probably it's the missing CSE there:
> >
> > <bb 3> :
> > _1 = (float) l_10;
> > _2 = _1 < 0.0;
> > zone1_17 = (int) _2;
> > if (_1 < 0.0)
> >
> > we are not considering to replace the FP compare control if (_1 < 0.0)
> > with an integer compare control if (_2 != 0). Maybe we should do that?
>
That would resolve the issue from VRPs point of view. _2 has no involvement in
the condition, sonother _2 nor zone1_17 are considered direct exports.
We do however recognize that it can be recomputed as it depends on _1. I have
not yet had a chance to extend relations to recomputations, (its probably not a
win very often as we assume CSE takes care fo those things)
I see we do make an attempt to recompute:
13 GORI recomputation attempt on edge 3->4 for _2 = _1 < 0.0;
14 GORI outgoing_edge for _1 on edge 3->4
15 GORI compute op 1 (_1) at if (_1 < 0.0)
GORI LHS =[irange] _Bool [1, 1]
GORI Computes _1 = [frange] float [-Inf, -0.0 (-0x0.0p+0)]
intersect Known range : [frange] float VARYING +-NAN
GORI TRUE : (15) produces (_1) [frange] float [-Inf, -0.0
(-0x0.0p+0)]
GORI TRUE : (14) outgoing_edge (_1) [frange] float [-Inf, -0.0
(-0x0.0p+0)]
GORI TRUE : (13) recomputation (_2) [irange] _Bool VARYING
folding _2 using the true edge value:
[-Inf, -0.0 (-0x0.0p+0)] < 0.0
is returning false, so we dont recognize that _2 is always true. I assume this
has something to do with the wonders of floating point and +/- 0:-)
