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 <20040308.132758.107685326.kazu@cs.umass.edu>, 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.

jeff



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