Re: [RFA] Factor conversion out of COND_EXPR using match.pd pattern

[Jeff Law <law at redhat dot com>]

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