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:-)