On Wed, Jul 30, 2014 at 3:36 PM, Prathamesh Kulkarni <bilbotheelffri...@gmail.com> wrote: > On Wed, Jul 30, 2014 at 6:44 PM, Richard Biener > <richard.guent...@gmail.com> wrote: >> On Wed, Jul 30, 2014 at 2:30 PM, Prathamesh Kulkarni >> <bilbotheelffri...@gmail.com> wrote: >>> On Wed, Jul 30, 2014 at 5:55 PM, Prathamesh Kulkarni >>> <bilbotheelffri...@gmail.com> wrote: >>>> On Wed, Jul 30, 2014 at 4:41 PM, Richard Biener >>>> <richard.guent...@gmail.com> wrote: >>>>> On Wed, Jul 30, 2014 at 12:49 PM, Prathamesh Kulkarni >>>>> <bilbotheelffri...@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