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