This is the mail archive of the
mailing list for the GCC project.
Re: writing patterns
- From: Prathamesh Kulkarni <bilbotheelffriend at gmail dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Wed, 30 Jul 2014 18:00:12 +0530
- 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>
On Wed, Jul 30, 2014 at 5:55 PM, Prathamesh Kulkarni
> On Wed, Jul 30, 2014 at 4:41 PM, Richard Biener
> <firstname.lastname@example.org> wrote:
>> On Wed, Jul 30, 2014 at 12:49 PM, Prathamesh Kulkarni
>> <email@example.com> wrote:
>>> 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)
>> (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.
> 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):
> (plus (minus@T@2 @0 @1) (mult@T @2 @3))
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.
>> 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
>> 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 ?