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