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

[Richard Biener <richard.guenther@gmail.com>]

On February 2, 2015 7:32:15 PM CET, Jeff Law <law@redhat.com> wrote:
>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.

Huh, that would be a bug.  Do you have a pattern where that happens?

Richard.

  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