Re: [patch] convert.c: Fix PR tree-optimization/25125. (Take 3)

[Dorit Naishlos <DORIT at il dot ibm dot com>]

> > There are two difficulties in the resulting pattern:
> >
> > 1. Because of the casts, reasociation ended up prefering this form:
> >       sum = (sum + b) - c
> > over this one:
> >       sum += (b - c);
> > whereas without the casts reassociation knows to prefer the second
form,
> > which makes it much easier later on for the vectorizer to dected the
> > reduction. (This is similar to the situation we had in
> > http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01799.html).
> > So one question is: can reassociation be tweaked to prefer the second
form
> > even in the presence of these casts?
>
> Not easily, because it doesn't see through casts at all.
>
> ...
>
> > If such a pass could take place even before reassociation, we wouldn't
have
> > to worry about tweaking reassociation.
> > What would be the most appropriate place to perform such "cast motion"
> > optimization?
>
> PRE could do it (and usually does).
>

it doesn't here... do you think this would qualify as a
missed-PRE-optimization PR?

>
> However, one of these days, we are just going to have to be able to
> recognize patterns like the above (I'm aware it's quite difficult).
>

maybe so, but even then, I think it's still a good optimization to have in
general (i.e. moving these casts out of the loop).

dorit

>
>