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
