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

[Richard Biener <richard dot guenther at gmail dot com>]

On Tue, Jun 2, 2015 at 7:33 PM, Jeff Law <law@redhat.com> wrote:
> 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.

Yes, I'd prefer the above.

I'll note down the syntax improvements and hope to get to them during
stage1.

Thanks,
Richard.

>>
>> 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