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: [PATCH] Fold sqrt comparisons against constants (take 3)


On Wed, 19 Mar 2003, Richard Henderson wrote:
> > + 	  /* sqrt(x) < y is always false, if y is negative.  */
> > + 	  if (code == EQ_EXPR || code == LT_EXPR || code == LE_EXPR)
> > + 	    return omit_one_operand (type,
> > + 				     convert (type, integer_zero_node),
> > + 				     arg);
> > +
> > + 	  /* sqrt(x) > y is always true, if y is negative and we
> > + 	     don't care about NaNs, i.e. negative values of x.  */
> > + 	  if (! HONOR_NANS (mode))
> > + 	    return omit_one_operand (type,
> > + 				     convert (type, integer_one_node),
> > + 				     arg);
> > +
> > + 	  /* sqrt(x) > y is the same as x >= 0, if y is negative.  */
> > + 	  return fold (build (GE_EXPR, type, arg,
> > + 			      build_real (TREE_TYPE (arg), dconst0)));
>
> Isn't this test always true for NE_EXPR, regardless of NANs?

Unfortunately, not.  sqrt(NaN) != -1  ->  NaN != -1  ->  false
                     sqrt(-1)  != -1  ->  NaN != -1  ->  false


> > + 	      /* sqrt(x) > y is x == +Inf, when y is very large.  */
> > + 	      /* sqrt(x) < y is x != +Inf when y is very large and we
> > + 	      /* sqrt(x) < y is x >= 0 && x != +Inf, when y is large.  */
>
> While these are all true and correct, I'd really prefer that
> we didn't compare against Inf directly, since this traps for
> emulation on Alpha and Mips (at least).
>
> Better is to test {>,<=} DBL_MAX.
>
> It should be easy to add a function to real.c that can build
> this constant for you for any particular fp type.


Funny you should mention that, but I have a follow-up patch to fold
so that comparisons against +Inf, -Inf and NaN are constant folded.
For example, x == __builtin_nan() and x > +Inf can always be turned
into false.  I hadn't appreciated that converting "x == +Inf" into
"x > DBL_MAX" would be a performance win, but this transformation
can/should be applied in the same "hunk".


As you realize its better to put these transformations at their own
appropriate location in "fold" and let the recursive calls in my
patch handle them rather than duplicate logic in fold_mathfn_compare.
This way they may be reused elsewhere including in the user's code.


Roger
--


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