This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tree-ssa] tree-ssa-dom.c: Fix PR 14303.


In message <Pine.LNX.4.44.0403080836410.28837-100000@www.eyesopen.com>, Roger S
ayle writes:
 >I believe the transformation fabs(x) < 0.0 into false is always safe
 >even in the presence of NaNs.  The reveresed form, fabs(x) >= 0.0
 >into true, however is unsafe as fabs(NaN) = NaN, so NaN >= 0.0 would
 >be false.
Ah OK.  Based on that, then going with Kazu's patch is reasonable in the
short term -- until such time as we can/do track FP ranges.

 >The logic is valid, however my comments to Kazu were that this might
 >be better handled your SSA "range bounds" infrastructure, such that
 >the lower bound on tree_expr_nonnegative_p was 0.0.  This not only
 >fixes "fabs(x) < 0.0" in the PR, but also "fabs(x) < -1.0" etc...
 >Similarly, if we don't care about NaNs (e.g. -ffast-math), it
 >should also optimize fabs(x) >= 0.0 and fabs(x) > -1.0.
Well, the range bounds stuff is currently designed to only handle integers,
not floats.    There's a lot of interesting issues when you start looking at
handling floats -- NaNs come immediately to mind.

The existing range should be considered a placeholder -- ultimately the range
stuff should be largely done in the CCP engine since that engine can do a
significantly better job at building range information (and probably do it
more efficiently than we could in DOM).


jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]