writing patterns

[Richard Biener]

On Thu, Jul 31, 2014 at 9:10 PM, Richard Sandiford
<rdsandiford@googlemail.com> wrote:
> Richard Biener <richard.guenther@gmail.com> writes:
>> On Wed, Jul 30, 2014 at 12:49 PM, Prathamesh Kulkarni
>> <bilbotheelffriend@gmail.com> wrote:
>>> Hi,
>>>    Sorry to ask a stupid question, but I am having issues writing patterns
>>> involving casts. I am trying to write patterns from simplify_rotate.
>>>
>>> Could you show me how to write a patterns that involve
>>> casts ?
>>> for eg:
>>> ((T) ((T2) X << CNT1)) + ((T) ((T2) X >> CNT2))     iff CNT1 + CNT2 == B
>>> T -> some unsigned type with bitsize B, and some type T2 wider than T.
>>> How to express this in the pattern ?
>>
>> [copying gcc@ because of the syntax stuff]
>>
>> for example with (leaving captures as the appear in the pattern above)
>>
>> (match_and_simplify
>>    (plus (convert@2 (lshift (convert@0 X) CNT1))
>>            (convert (rshift (convert@1 X) CNT2)))
>>     /* Types T2 have to match */
>>    (if (types_compatible_p (TREE_TYPE (@0), TREE_TYPE (@1))
>>         /* Type T should be unsigned.  */
>>        && TYPE_UNSIGNED (TREE_TYPE (@2))
>>        /* T2 should be wider than T.  */
>>        && TYPE_PRECISION (TREE_TYPE (@0)) > TYPE_PRECISION (TREE_TYPE (@2))
>>        /* CNT1 + CNT2 == B */
>>        && wi::eq_p (TYPE_PRECISION (TREE_TYPE (@2)),
>>                            wi::add (CNT1, CNT2))))
>>    (lrotate CNT1))
>>
>> which suggests that we may want to add some type capturing / matching
>> so we can maybe write
>>
>>   (plus (convert@T (lshift (convert@T2 X) CNT1))
>>           (convert (rshift (convert@T2 X) CNT2)))
>>   (if (/* T2s will be matched automagically */
>>        && TYPE_UNSIGNED (@T)
>>        && TYPE_PRECISION (@T2) > TYPE_PRECISION (@T)
>>        && wi::eq_p (TYPE_PRECISION (@T), wi::add (CNT1, CNT2))))
>>
>> which is less to type and supports requiring matching types.  Maybe
>> require @T[0-9]+ here thus use @T0 and disallow plain @T.  We could
>> then also use @T for the implicitely "captured" outermost type we
>> refer to as plain 'type' right now.
>
> Would it also be worth trying to push more of the type properties into
> the pattern, a bit like md predicates?  (Not the same syntax though,
> obviously.)  Was just thinking that postponing things like
> "TYPE_UNSIGNED (@T)" until the whole tree has been matched could
> be inefficient in some cases.

Maybe, but as we are using a decision tree for the matching it's
not so easy to handle this kind of checks efficiently (compared
to a simple switch cascade on TREE_CODE).

Richard.

> Might be going over old ground though, sorry.
>
> Richard