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

Reply via email to