On Mon, Jul 14, 2014 at 6:35 PM, Richard Biener <richard.guent...@gmail.com> wrote: > On Mon, Jul 14, 2014 at 12:07 PM, Prathamesh Kulkarni > <bilbotheelffri...@gmail.com> wrote: >> I was wondering if it was a good idea to implement >> predicate on expressions ? >> >> Sth like: >> (match_and_simplify >> (op (op2:predicate @0)) >> transform) >> >> instead of: >> (match_and_simplify >> (op (op2@1 @0)) >> if (predicate (@1)) >> transform) >> >> When predicate is simple as just being a macro/function, >> we could use this style and when the predicate is more complex >> resort to using if-expr (or write the predicate as macro in >> gimple-match-head.c >> and use the macro in pattern instead ...) >> >> Example: >> we could rewrite the pattern >> (match_and_simplify >> (plus:c @0 (negate @1)) >> if (!TYPE_SATURATING (type)) >> (minus @0 @1)) >> >> to >> >> (match_and_simplify >> (plus:c:NOT_TYPE_SATURATING_P @0 (negate @1)) >> (minus @0 @1)) >> >> with NOT_TYPE_SATURATING_P predicate defined >> appropriately in gimple-match-head.c >> >> However I am not entirely sure if adding predicates on expressions >> would be very useful.... > > Well. I think there are two aspects to this. First is pattern > readability where I think that the if-expr form is more readable. > Second is the ability to do less work in the code generated > from the decision tree. > > For example most of the patterns from associate_plusminus > still miss the !TYPE_SATURATING && !FLOAT_TYPE_P && > !FIXED_POINT_TYPE_P if-expr. That is, we'd have > > /* (A +- B) - A -> +-B. */ > (match_and_simplify > (minus (plus @0 @1) @0) > if (!TYPE_SATURATING (type) > && !FLOAT_TYPE_P (type) && !FIXED_POINT_TYPE_P (type)) > @1) > (match_and_simplify > (minus (minus @0 @1) @0) > if (!TYPE_SATURATING (type) > && !FLOAT_TYPE_P (type) && !FIXED_POINT_TYPE_P (type)) > (negate @1)) > /* (A +- B) -+ B -> A. */ > (match_and_simplify > (minus (plus @0 @1) @1) > if (!TYPE_SATURATING (type) > && !FLOAT_TYPE_P (type) && !FIXED_POINT_TYPE_P (type)) > @0) > (match_and_simplify > (plus:c (minus @0 @1) @1) > if (!TYPE_SATURATING (type) > && !FLOAT_TYPE_P (type) && !FIXED_POINT_TYPE_P (type)) > @0) > > with code-generation checking the if-expr after matching. And > with using expression predicates we'd be able to check the > predicate when matching the outermost 'minus' and "CSE" > the predicate check for the first three patterns. Runtime-wise > it depends on whether there is a point to back-track to. > > I would say it's more interesting to support > > if (!TYPE_SATURATING (type) && !FLOAT_TYPE_P (type) && > !FiXED_POINT_TYPE_P (type)) > (match_and_simplify ....) > (match_and_simplify ....) > .... > > and treat this if-expression like a predicate on the outermost > expression. That's getting both benefits > (bah, the free-form if-expr makes it ugly, what do we use as > grouping syntax? I guess wrapping the whole thing in ()s, > similar to (for ...)). Um, I was wondering instead of defining new syntax if it would be better to make genmatch detect common if-expr and hoist them ? I suppose we could compare if-expr's lexicographically ?
However I guess having some syntax to group common if-expr patterns explicitly would avoid the need for writing the if-expr in each pattern. For now should we go with free-form if ? If desired, we could change syntax later to something else (only parsing code need change, the rest would be in place). If we change the syntax for outer-if, for consistency should we also change syntax of inner if ? Thanks and Regards, Prathamesh > > Richard. > >> Thanks and Regards, >> Prathamesh
