On Fri, 2011-05-27 at 12:24 +0200, Richard Guenther wrote:
<snip>
> Now, the tree_expr_nonnegative_p check will always return false
> because arg0 is a gimple value. We would need to implement
> either some propagation engine to derive properties for floating
> point entities or mimic what tree_expr_nonnegative_p does by
> looking at defining statements. A very simple variant could be
> like
>
> bool
> gimple_val_nonnegative_p (tree val)
> {
> if (tree_expr_nonnegative_p (val))
> return true;
>
> if (TREE_CODE (val) == SSA_NAME)
> {
> gimple def_stmt = SSA_NAME_DEF_STMT (val);
> if (is_gimple_assign (def_stmt))
> return gimple_assign_rhs_code (def_stmt) == ABS_EXPR;
> else if (is_gimple_call (def_stmt))
> {
> tree fndecl = gimple_call_fndecl (def_stmt);
> if (fndecl
> && DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL)
> {
> switch (DECL_FUNCTION_CODE (fndecl))
> {
> CASE_FLT_FN (BUILT_IN_FABS):
> return true;
> default:;
> }
> }
> }
> }
>
> return false;
> }
>
> suitable for gimple-fold.c.
>
> Alternatively you can drop the call and add a FIXME comment.
>
> > +
> > + /* Optimize pow(x,1./6.) = cbrt(sqrt(x)). Don't do this optimization
> > + if we don't have a hardware sqrt insn. */
> > + dconst1_6 = dconst1_3;
> > + SET_REAL_EXP (&dconst1_6, REAL_EXP (&dconst1_6) - 1);
> > +
> > + if (flag_unsafe_math_optimizations
> > + && sqrtfn
> > + && cbrtfn
> > + && (tree_expr_nonnegative_p (arg0) || !HONOR_NANS (mode))
>
> Likewise.
OK, sounds good. I will commit this patch with the FIXME comments, and
test the gimple_val_nonnegative_p changes next week after the holiday.
Thanks,
Bill
