Serious performance regression -- some tree optimizer questions

[Ulrich Weigand]

Zdenek Dvorak <rakdver@atrey.karlin.mff.cuni.cz> wrote on 12/20/2004
11:52:07 PM:

> 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.

>       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 ...

>       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 ...)


Mit freundlichen Gruessen / Best Regards

Ulrich Weigand

--
  Dr. Ulrich Weigand
  Linux for S/390 Design & Development
  IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen
  Phone: +49-7031/16-3727   ---   Email: Ulrich.Weigand@de.ibm.com