Re: writing patterns

[Prathamesh Kulkarni <bilbotheelffriend at gmail dot com>]

On Wed, Jul 30, 2014 at 6:44 PM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On Wed, Jul 30, 2014 at 2:30 PM, Prathamesh Kulkarni
> <bilbotheelffriend@gmail.com> wrote:
>> On Wed, Jul 30, 2014 at 5:55 PM, Prathamesh Kulkarni
>> <bilbotheelffriend@gmail.com> wrote:
>>> On Wed, Jul 30, 2014 at 4:41 PM, Richard Biener
>>> <richard.guenther@gmail.com> wrote:
>>>> 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))))
>>>>
>>> Thanks.
>>>> 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.
>>> What if we need to capture "value" as well as "type" ?
>>> for instance match type with another capture, and value with a
>>> different capture ?
>>>
>>> sth like: (bogus pattern):
>>> (match_and_simplify
>>>   (plus (minus@T@2 @0 @1) (mult@T @2 @3))
>>>   transform)
>> oops, @T was meant for outermost expression.
>> sth like: (plus (minus@T0@2 @0 @1) (mult@T0 @2 @3))
>> however this doesn't look good.
>
> Yeah...  well.  I don't see very many compelling reasons for this
> kind of cross-match but didn't think of the matching case initially
> (otherwise capturing an expression is a "super-set" of capturing
> its type as you can get at its type with TREE_TYPE (@0)).
I was wondering if it would be a good idea to have "capture expressions" ?
sth like:
(plus (minus@2 @0 @1) (mult@(type @2) @2 @3))

(type @2) would only match type with the given catpure (@2), and not
the whole thing.
If we also need to capture mult-node, it would be written as:
(plus (minus@2 @0 @1) (mult@4(type @2) @2 @3))


Thanks,
Prathamesh
>
> I guess we can add support when need arises.
>
> Richard.
>
>>>
>>>> I suggest to go ahead without a new syntax for now and see if it
>>>> gets unwieldingly ugly without first.
>>>>
>>>>> For this week, I have planned:
>>>>> a) writing patterns from simplify_rotate
>>>>> b) replacing op in c_expr
>>>>> c) writing more test-cases.
>>>>>
>>>>> If there's anything else you would like me to do, I would be happy
>>>>> to know.
>>>>
>>>> Just keep an eye open for things like above - easy ways to reduce
>>>> typing for patterns.
>>>>
>>>> Btw, I suggest to split up match.pd by code you converted from.  Thus
>>>> for simplify_rotate add
>>>>
>>>>   match-simplify-rotate.pd
>>>>
>>>> with the patterns and do a #include "match-simplify-rotate.pd"
>>>> in match.pd.  That will make it easier to match the two later.
>>> Okay, should I correspondingly split bitwise patterns in
>>> match-simplify-bitwise.pd and the rest ?
>>>
>>> Thanks,
>>> Prathamesh
>>>
>>>>
>>>> Thanks,
>>>> Richard.
>>>>
>>>>
>>>>> Thanks,
>>>>> Prathamesh