This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] tree-ssa-dom.c: Fix PR 14303.
- From: Roger Sayle <roger at eyesopen dot com>
- To: law at redhat 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, 8 Mar 2004 08:50:33 -0700 (MST)
- Subject: Re: [tree-ssa] tree-ssa-dom.c: Fix PR 14303.
On Sun, 7 Mar 2004 email@example.com wrote:
> Based in the comments in the PR, I do not think this is correct due to
> not properly handling NaNs.
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
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.
> The PR references the following:
Signaling NaNs are an additional set of problems. However, the above
proposal documents that neg and abs are exceptions that are not required
to raise an exception even with signaling NaNs. This permits their
implementation with bit-operations. If it wasn't for this caveat, I
agree we'd have to guard Kazu's transformation with flag_signaling_nans.
I haven't looked at the range bounds code and data structures on tree-ssa.
Does it contain provisions for tracking whether a floating point variable
can hold a NaN in additional to its upper and lower bound? I think medium
term that infrastructure provides a much better framework for PR 14303.