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.


On Sun, 7 Mar 2004 law@redhat.com wrote:
> Based in the comments in the PR, I do not think this is correct due to
> not properly handling NaNs.

Hi Jeff,

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.


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:
> http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/n819.htm

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.

Roger
--


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