On Thu, Jul 31, 2014 at 9:10 PM, Richard Sandiford <rdsandif...@googlemail.com> wrote: > Richard Biener <richard.guent...@gmail.com> writes: >> 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)))) >> >> 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. > > Would it also be worth trying to push more of the type properties into > the pattern, a bit like md predicates? (Not the same syntax though, > obviously.) Was just thinking that postponing things like > "TYPE_UNSIGNED (@T)" until the whole tree has been matched could > be inefficient in some cases.
Maybe, but as we are using a decision tree for the matching it's not so easy to handle this kind of checks efficiently (compared to a simple switch cascade on TREE_CODE). Richard. > Might be going over old ground though, sorry. > > Richard
