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 <gcc at gcc dot gnu dot org>
- Date: Mon, 11 Aug 2014 14:22:36 +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> <CAFiYyc2JyG=jam0XTB3hdyCvmPoN_LFLXW8ca=vcwZnejczj_w at mail dot gmail dot com> <CAJXstsDXyHwQK+dSwyuHPXoDqKv=bceDTL4Yr2Od4YYF6ROXYQ at mail dot gmail dot com> <CAJXstsCfBYf3Z6siL3R6dJ8xrCq6VqJi_c5+uZHVv6QPkLaptQ at mail dot gmail dot com> <CAFiYyc3OC38E2WNpMKfZLGfGLac69QLPJEnbFhLBteOuMPoKwg at mail dot gmail dot com> <CAJXstsAfYKqPwQq58sSaCRPoiMoc9Bs0794qXwvwVvjEG-hdMQ at mail dot gmail dot com> <CAFiYyc2DNWViyx9hK9GkuLzN=9pXLPSXfFwb75w+gvXv12Vr3Q at mail dot gmail dot com> <CAJXstsB4qUdOhfxUtQ5YPzBBtxTBB81nWfQEu0UtXs6BonUohg at mail dot gmail dot com> <CAJXstsB-b37c3VB2VhLXy_6sH=4e9vvP8h8VfeWrE=2Hi1wTyg at mail dot gmail dot com> <CAFiYyc2RxaiCeGD-6GpgSQv9QcjPgdsvk-ww204m+w7C0g-ySQ at mail dot gmail dot com> <CAJXstsAOEJYRvzte+hteX-xbr3u=7vUbftQdJhgznfnftZGNHQ at mail dot gmail dot com> <CAFiYyc1ZzM-hOwGtnx7BMJpBVGervhsUV1o3JiHRFgPf0XyFGw at mail dot gmail dot com> <CAJXstsB9oygv2qhyef1QjV_Mmv7GLf+hhzvsnHC-k8EDG2LXnA at mail dot gmail dot com> <CAJXstsDkZ2JtCpoD69b9TibneNOz_5aL3Ke2tZC9xZ4dWh=pJQ at mail dot gmail dot com>
On Mon, Aug 11, 2014 at 1:06 AM, Prathamesh Kulkarni
<bilbotheelffriend@gmail.com> wrote:
> On Mon, Aug 11, 2014 at 2:53 AM, Prathamesh Kulkarni
> <bilbotheelffriend@gmail.com> wrote:
>> On Tue, Aug 5, 2014 at 3:15 PM, Richard Biener
>> <richard.guenther@gmail.com> wrote:
>>> On Mon, Aug 4, 2014 at 4:44 PM, Prathamesh Kulkarni
>>> <bilbotheelffriend@gmail.com> wrote:
>>>> On Mon, Aug 4, 2014 at 2:59 PM, Richard Biener
>>> No, not changing tree.def but its use as you did in your first proposed
>>> patch.
>> I have got it done except for capturing optional converts.
>> for instance (negate (convert1@0 @1)) does not work.
>> This is because of insertion in decision tree (insert::operand).
That's because you lower it to
(negate @0@1)
right? a capture with ->what being a capture itself? That's reasonable
btw.
>> Since captures were always predicate or expressions,
>> ie, the corresponding dt-node->type was dt_node::DT_OPERAND,
>> i could hard-code for a search on dt_node::DT_OPERAND.
>> This changes when capture itself can be captured (dt_node::DT_TRUE/DT_MATCH),
>> and there's no easy way right now to obtain corresponding
>> dt-node from a given operand node.
>>
>> Should we keep a mapping (hash_map/std::map) from operand * to dt_node * ?
>> That will also get rid of dt_node::parent (but we need to then
>> introduce parent in AST).
>>
>> Other cases where convert1, convert2 are not captured work
>> fine.
>> (bit_not (convert1 @0) (convert2 @1))
>> I have attached patch for reference (don't intend to get it committed).
>
> I have fixed it in a hackish way in the current patch, so capturing
> optional convert works..
> Since we don't know type corresponding to capture in decision tree
> :DT_TRUE/DT_MATCH (unless
> we get hold of dt-node corresponding to the capture), I tried both the
> possibilities.
That looks reasonable to me though I manage to hit the assert with
(simplify
(plus (convert1@1 (plus@2 INTEGER_CST_P INTEGER_CST_P)) @3)
(if (useless_type_conversion_p (TREE_TYPE (@1), TREE_TYPE (@2))))
@2)
when ->what is an expression.
I'd also like the various compares against CONVERT1/2 to be not done
as string compares but using enum tree_code CONVERT1
equality checks.
I have fixed that (but not the above insertion issue) and committed the
patch.
Note that I'd still like the syntax to include a question mark, thus
convert?, convert1? or convert2? should be conditional converts.
Requires a parser hack though.
Thanks,
Richard.
> * genmatch.c (enum tree_code): Add new values CONVERT1, CONVERT2.
> (lower_opt_convert): New function.
> (lower_opt_convert): New function overloaded.
> (lower_opt_convert): Likewise.
> (lower_opt_convert): Likewise.
> (remove_opt_convert): New function.
> (has_opt_convert): Likewise.
> (decision_tree::insert_operand): Adjust for capturing a capture.
> (parse_for): Reject CONVERT1, CONVERT2.
> (main): call add_operator.
> call lower_opt_convert.
>
> Thanks,
> Prathamesh
>>
>> Thanks,
>> Prathamesh
>>>
>>> Richard.
>>>
>>>> Thanks,
>>>> Prathamesh
>>>>>
>>>>> Richard.
>>>>>
>>>>>>
>>>>>> * genmatch.c (enum tree_code): New value OPT_CONVERT.
>>>>>> (e_operation): New member unsigned group_index.
>>>>>> (e_operation::e_operation): Add new default argument.
>>>>>> Adjust to changes in e_operation.
>>>>>> (remove_opt_convert): New function.
>>>>>> (has_opt_convert): Likewise.
>>>>>> (lower_opt_convert): Likewise.
>>>>>> (lower_opt_convert): New overloaded function.
>>>>>> (lower_opt_convert): Likewise.
>>>>>> (parse_expr): Adjust to parse opt_convert.
>>>>>> (parse_for): Reject opt_convert in opers.
>>>>>> (main): Call lower_opt_convert.
>>>>>>
>>>>>> Thanks,
>>>>>> Prathamesh
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Prathamesh.
>>>>>>>>
>>>>>>>> Richard.
>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Prathamesh
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Richard.
>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Prathamesh
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Prathamesh
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Extending for in this way avoids treating conversions specially
>>>>>>>>>>>>> (I don't see an easy way to do very good at that automagically). We
>>>>>>>>>>>>> need multiple patterns in the decision tree here anyway.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Now guess sth fancy in place of '*' ...
>>>>>>>>>>>>>
>>>>>>>>>>>>> Lisp style would be less free-form like
>>>>>>>>>>>>>
>>>>>>>>>>>>> (for cvt (convert ())
>>>>>>>>>>>>>
>>>>>>>>>>>>> where we could use an empty list for the "empty" operator.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Is nested for support already implemented?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Richard.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Richard.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Prathamesh