This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: writing patterns
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Prathamesh Kulkarni <bilbotheelffriend at gmail dot com>
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Wed, 30 Jul 2014 16:11:26 +0200
- Subject: Re: writing patterns
- Authentication-results: sourceware.org; auth=none
- References: <CAJXstsDfsQbj4e-RVyGC0grF_UDx5J0pYh=M9H9w=VYA-HBY4w at mail dot gmail dot com> <CAFiYyc0mAyTVrn07+ZSzgRT3of=O90iKkM_HVo1MfTvZaJemvw at mail dot gmail dot com> <CAJXstsDeBzQiDeNhXOdQJKuFPvpyN_14q4nqHBmADLaboC_pJQ at mail dot gmail dot com> <CAJXstsB_tjuZY9rbdY5xgMbMitJGSnUcW+ZQrNnsU0JGLSBmdg at mail dot gmail dot com> <CAFiYyc0vMPTrXwTqjKQRvzzZ0XUp=7=y_eaPrWTK3vhSwJcvcw at mail dot gmail dot com> <CAJXstsAxiqJ97SdbvR5hhfwvo3Y=Kyh_msC=_A-SkDGyM+uOqQ at mail dot gmail dot com>
On Wed, Jul 30, 2014 at 3:36 PM, Prathamesh Kulkarni
<bilbotheelffriend@gmail.com> wrote:
> 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))
Huh, that get's a bit too complicated for my taste ;) As always I want
to see an actual pattern that would benefit a lot from this kind of
new features.
Richard.
>
> 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