On Mon, Jul 14, 2014 at 10:52 PM, Prathamesh Kulkarni <bilbotheelffri...@gmail.com> wrote: > 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.
Yeah, the main motiviation is to make the patterns itself easier to read and group them by boiler-plate if-exprs. > For now should we go with free-form if ? I'd say (if (!TYPE_SATURATING (type) ....) <patterns...> ) thus wrap the if inside ()s. Otherwise there would be no way to "end" an 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 ? Probably yes, let's wrap the inner if inside ()s as well. Code-generation-wise we should record a vector of if-exprs and thus evaluate the outer ifs at the same place we evaluate inner if-exprs. Thanks, Richard. > Thanks and Regards, > Prathamesh >> >> Richard. >> >>> Thanks and Regards, >>> Prathamesh
