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: Kazu Hirata <kazu at cs dot umass dot edu>
- Cc: roger at eyesopen dot com, gcc-patches at gcc dot gnu dot org, pinskia at physics dot uc dot edu
- Date: Mon, 08 Mar 2004 11:59:25 -0700
- Subject: Re: [tree-ssa] tree-ssa-dom.c: Fix PR 14303.
- Reply-to: law at redhat dot com
In message <firstname.lastname@example.org>, Kazu Hirata writes:
>Hi Jeff and Roger,
>> >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.
>Does this mean the patch is OK to apply?
Well, there are some things it could definitely do better.
For example, rather than using REAL_VALUES_EQUAL (TREE_REAL_CST (op1), dconst0)
it seems to me you ought to be able to use something like:
real_compare (GE_EXPR, TREE_REAL_CST (op1), dconst0)
That would allow you to optimize more cases.
I think with that change you should be OK for the medium term. As I mentioned
to Roger, longer term we need to be recording range information for each
SSA_NAME node rather than just SSA_NAMEs which were used in conditionals. Once
that work is in place you would not need to fall the def-use chain for op0.
> One thing I am worried about is that no part of tree-ssa-dom.c has an
> expression transformation as bold as my patch.
I'm not exactly sure what you mean by that.
> Should I build a dummy tree node and have fold() fold it?
That should not be necessary.