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

[Daniel Berlin <dberlin at dberlin dot org>]

On Thu, 2005-12-29 at 13:44 +0200, Dorit Naishlos wrote:
> Roger Sayle <roger@eyesopen.com> wrote on 26/12/2005 23:30:38:
> > ....
> >
> > Hopefully the vectorization folks will let us know if its a
> > trivial task to enhance the vectorization pattern matching code
> > to handle these sign-changing type conversions,
> 
> Sorry for the delayed response.
> 
> Cases like vect-7.c I expect would be easy to overcome by detecting the
> sign-changing pattern in the vectorizer (I actually just submitted the
> vectorizer's pattern-detection infrastructure for inclusion in 4.2; we
> could easily add this pattern on top of that infrastructure).
> 
> Cases like vect-reduc-2char/vect-reduc-2short would be harder to handle in
> the vectorizer, because it makes a simple reduction that should have looked
> like this:
> 
> loop:
>   # diff_41 = PHI <diff_39(4), 2(2)>;
>   D.2380_31 = b[i_16];
>   D.2382_34 = c[i_16];
>   D.2384_36 = D.2381_31 - D.2383_34;
>   diff_39 = D.2384_36 + diff.6_41;
> loop_end
> 
> to look like this:
> 
> loop:
>   # diff_41 = PHI <diff_39(4), 2(2)>;
>   D.2380_31 = b[i_16];
>   D.2381_32 = (unsigned char) D.2380_31;
>   D.2382_34 = c[i_16];
>   D.2383_35 = (unsigned char) D.2382_34;
>   diff.6_37 = (unsigned char) diff_41;
>   D.2384_36 = D.2381_32 + diff.6_37;
>   D.2386_38 = D.2384_36 - D.2383_35;
>   diff_39 = (signed char) D.2386_38;
> loop_end
> 
> 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). 


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