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] Fix bitfield-- != 0 transformation in fold-const.c


On Sat, 6 Mar 2004, Paolo Bonzini wrote:
> !    /* This optimization is invalid for ordered comparisons
> !       if CONST+INCR overflows or if foo+incr might overflow.
> !       This optimization is invalid for floating point due to rounding.
> !       For pointer types we assume overflow doesn't happen.  */
> !    && (POINTER_TYPE_P (TREE_TYPE (arg0))
> !        || (INTEGRAL_TYPE_P (TREE_TYPE (arg0))
> !     && (code == EQ_EXPR || code == NE_EXPR))))
>
> What about checking for unsignedness or -fwrapv here?  Something like
>
> (POINTER_TYPE_P (TREE_TYPE (arg0))
>   || (INTEGRAL_TYPE_P (TREE_TYPE (arg0))
>       && (code == EQ_EXPR || code == NE_EXPR ||
>                flag_wrapv || TREE_UNSIGNED (TREE_TYPE (arg0))))


Unfortunately not.  This transformation is not valid for the other
ordering operations, such as LT_EXPR, GE_EXPR etc...

Consider the following counter example, for unsigned short x,
"x-- > 0" is not equivalent to "--x > 65535".  Notice that this
transformation only works for equality and inequality.

Infact one might argue that this transformation is already assuming well
behaved overflow, so theoretically it should ideally be written as.

(POINTER_TYPE_P (TREE_TYPE (arg0))
  || (INTEGRAL_TYPE_P (TREE_TYPE (arg0))
      && (code == EQ_EXPR || code == NE_EXPR)
      && (flag_wrapv || TREE_UNSIGNED (TREE_TYPE (arg0))))

But this would have the immediate effect of just disabling this
transformation for signed integers under default conditions.

Longer term, it would be nice to switch GCC to set flag_wrapv as a
default, so that we can tighten these conditions without risking
severe performance regressions.  That clean-up however was not the
intention of this kernel-affecting regression fix.


I'd even considered enabling this transformation for floating point
types with -ffast-math, but there seemed little benefit as I doubt
that anyone has ever written "real++ != 5.2"...

Roger
--


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