On 06/01/2015 05:07 AM, Richard Biener wrote:
+(simplify
+ (cond @0 (convert @1) INTEGER_CST@2)
+ (if (INTEGRAL_TYPE_P (TREE_TYPE (@1))
+ && COMPARISON_CLASS_P (@0)
+ && int_fits_type_p (@2, TREE_TYPE (@1))
+ && ((operand_equal_p (TREE_OPERAND (@0, 0), @2, 0)
+ && operand_equal_p (TREE_OPERAND (@0, 1), @1, 0))
+ || (operand_equal_p (TREE_OPERAND (@0, 0), @1, 0)
+ && operand_equal_p (TREE_OPERAND (@0, 1), @2, 0))))
+ (with { tree itype = TREE_TYPE (@1); tree otype = TREE_TYPE (@2); }
+ (convert:otype (cond:itype @0 @1 (convert:itype @2))))))
+
+(simplify
+ (cond @0 INTEGER_CST@1 (convert @2))
+ (if (INTEGRAL_TYPE_P (TREE_TYPE (@2))
+ && COMPARISON_CLASS_P (@0)
+ && int_fits_type_p (@1, TREE_TYPE (@2))
+ && ((operand_equal_p (TREE_OPERAND (@0, 0), @2, 0)
+ && operand_equal_p (TREE_OPERAND (@0, 1), @1, 0))
+ || (operand_equal_p (TREE_OPERAND (@0, 0), @1, 0)
+ && operand_equal_p (TREE_OPERAND (@0, 1), @2, 0))))
+ (with { tree itype = TREE_TYPE (@2); tree otype = TREE_TYPE (@1); }
+ (convert:otype (cond:itype @0 (convert:itype @1) @2)))))
Now this is a case where :c support on cond would make sense...
Yea. The trick would be describing which operands can commute since
COND_EXPR has 3 operands. I guess we could just define it in the
obvious way for COND_EXPR and special case it wherever we need.
in
theory the preprocessor would also be your friend here. Or we could
enhance the syntax to support multiple match patterns for the same
result, thus
(simplify
(cond @0 (convert @1) INTEGER_CST@2)
(cond @0 INTEGER_CST@2 (convert @1))
(if ...
though that would require some extra markup to see where the list of matches
ends. user-defined predicates can be used for this already though
(match (widening_cond @0 @1 @2)
(cond @0 (convert @1) INTEGER_CST@2))
(match (widening_cond @0 @1 @2)
(cond @0 INTEGER_CST@2 (convert @1)))
(simplify
(widening_cond @0 @1 @2)
(if (...
If you'd prefer this syntax, I'm happy to switch to it and simplify
later if we gain :c support on the COND_EXPR.
but the comments from Marc still holds in that you shouldn't rely
on @0 being GENERIC - you want a GIMPLE testcase as well for this,
sth like
_Bool cond = 64 < mode_size[mode];
return cond ? 64 : mode_size[mode];
Yea, I'll poke at that to generate some gimple tests.
Not sure if I'll get another iteration out before heading on PTO or not.
Thanks for the feedback,
Jeff