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