This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Serious performance regression -- some tree optimizer questions
Hello,
> > here is some basic implementation of the idea; I don't know whether it
> > will help in your case, from what you say it seems to me that it needs
> > to be a bit improved first.
>
> Thank you for looking into this! Unfortunately the patch isn't quite
> sufficient yet -- while it does recognize that the 'basic' induction
> variables like i1 cannot overflow, it doesn't recognize that 'derived'
> variables like (i1 + 1) cannot overflow either.
>
> The reason appears to be that the CHREC_NO_OVERFLOW flag is not
> propagated through various folding operations on chrecs, like
> chrec_fold_plus, chrec_fold_minus, and even chrec_convert itself.
>
> It would appear to be correct to set the CHREC_NO_OVERFLOW flag
> on the result of chrec_fold_plus, say, if the inputs are either
> invariant or themselves cannot overflow, and the current data type
> is also such that the operation to be folded cannot overflow.
yes, I plan to do this now.
> > case PLUS_EXPR:
> > + /* Signed arithmetics does not wrap unless -fwrapv. */
> > + if (!TYPE_UNSIGNED (type_rhs)
> > + && !flag_wrapv)
> > + cannot_overflow = true;
>
> Don't we need to test for !flag_trapv as well? If flag_trapv
> is in effect, the optimizers may not remove potentially overflowing
> instructions to my understanding ...
Umm... right. Although we know that the operation does not overflow
(since otherwise there would be a trap), we should not claim that the
chrec cannot overflow in this case.
> > case MINUS_EXPR:
> > + /* Signed arithmetics does not wrap unless -fwrapv. */
> > + if (!TYPE_UNSIGNED (type_rhs)
> > + && !flag_wrapv)
> > + cannot_overflow = true;
>
> Likewise. (I guess it would make sense to abstract this into a
> TYPE_CANNOT_OVERFLOW macro or so ...)
Thinking about it, I probably saw some similar macro somewhere...
definitely something like that should be used.
Zdenek