This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] tree-ssa-dom.c: Fix PR 14303.
- From: law at redhat dot com
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: Kazu Hirata <kazu at cs dot umass dot edu>, gcc-patches at gcc dot gnu dot org, pinskia at physics dot uc dot edu
- Date: Mon, 08 Mar 2004 10:34:23 -0700
- Subject: Re: [tree-ssa] tree-ssa-dom.c: Fix PR 14303.
- Reply-to: law at redhat dot com
In message <Pine.LNX.firstname.lastname@example.org>, Roger S
>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
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).