Hi Richard,
> Oh, I see - that's very special then and the pattern in the comment
> does not include this conversion. I think you can simplify the checking
> done by requiring types_match (TREE_TYPE (@1), TREE_TYPE (@3))
> and by noting that the types of @0, @2 and @4 are the same
> (you don't seem to use @2).
>
> I wonder how relevant these kind of patterns are? Probably clang
> catches this simplification while we don't?
Yes. The bug report was based on a comparison with clang.
> Btw, you fail to check for INTEGRAL_TYPE_P, the whole thing
> would also match floats as-is, I think the easiest thing would be to
> change the match to
>
> + (op (plus:c (convert@0 @1) INTEGER_CST@4) (plus:c (convert@2 @3)
> INTEGER_CST@4))
>
> where you then also can elide the CONSTANT_CLASS_P (@4) check.
Thanks. I did miss checking for INTEGRAL_TYPE_P, and I didn't think to
use INTEGER_CST.
> Btw, for
>
> unsigned x, y;
> if (x + 0x80000000 < y + 0x80000000)
>
> it would be valid to transform this into
>
> if ((int)x < (int)y)
>
> which is a simplification that's worthwhile as well I think? So we
> might not actually
> need the (convert ...) but rely on (convert (convert @0)) being
> simplfiied? You'd
> then use
>
> (with { stype = signed_type_for (TREE_TYPE (@1)); }
> (op (convert:stype @1) (convert:stype @3)))
>
> as transform.
Thank you for all the hints! I'm going to work a v2 based on these.
Cheers,
Arjun
