https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrew Macleod from comment #9)
> (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:-)
Yes, -0.0 is not < 0.0, it's equal. So the "bug" is
> 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)]
_1 shoud be [-Inf, nextafter (0.0, -Inf)], not [-Inf, -0.0]
The issue seems to be that frange_nextafter used in build_lt uses
real_nextafter and for 0.0 that produces a denormal (correctly so I think)
but then we do flush_denormals_to_zero () in frange::set which makes
a -0.0 out of this.
Not sure why we treat denormals this way (guess we're just "careful").
"Fixing" this then yields
GORI TRUE : (186) recomputation (_2) [irange] _Bool [1, 1]
3->4 (T) _2 : [irange] _Bool [1, 1]
but this doesn't seem to help the PHI range in the successor?
=========== BB 3 ============
Imports: _1
Exports: _1
_2 : _1(I)
zone1_17 : _1(I) _2
l_10 [irange] int [-2147483646, 0]
<bb 3> :
_1 = (float) l_10;
_2 = _1 < 0.0;
zone1_17 = (int) _2;
if (_1 < 0.0)
goto <bb 4>; [INV]
else
goto <bb 5>; [INV]
I don't see any recompute for zone1_17 from the [1,1] _2 we recomputed?
