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)) 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
