Re: [RFC][PR target/39726 P4 regression] match.pd pattern to do type narrowing

[Jeff Law <law at redhat dot com>]

On 02/02/15 01:57, Richard Biener wrote:
> > The nice thing about wrapping the result inside a convert is the types for
> > the inner operations will propagate from the type of the inner operands,
> > which is exactly what we want.  We then remove the hack assigning type and
> > instead the original type will be used for the outermost convert.
>
> It's not even a hack but wrong ;)  Correct supported syntax is
>
> +     (with { tree type0 = TREE_TYPE (@0); }
> +      (convert:type0 (bit_and (inner_op @0 @1) (convert @3)))))))
>
> Thus whenever the generator cannot auto-guess a type (or would guess
> the wrong one) you can explicitely specify a type to convert to.
I found that explicit types were ignored in some cases.  It was 
frustrating to say the least.  But I think I've got this part doing what 
I want without the hack.

> Why do you restrict this to GENERIC?  On GIMPLE you'd eventually
> want to impose some single-use constraints as the result with all
> the conversions won't really be unconditionally "better"?
That was strictly because of the mismatch between the resulting type and 
how it was later used.  That restriction shouldn't be needed anymore.

Jeff