This is the mail archive of the
`gcc@gcc.gnu.org`
mailing list for the GCC project.

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |

Other format: | [Raw text] |

*From*: Richard Biener <richard dot guenther at gmail dot com>*To*: Prathamesh Kulkarni <bilbotheelffriend at gmail dot com>*Cc*: Diego Novillo <dnovillo at google dot com>, gcc <gcc at gcc dot gnu dot org>, Maxim Kuvyrkov <maxim dot kuvyrkov at linaro dot org>*Date*: Mon, 14 Jul 2014 15:05:47 +0200*Subject*: Re: predicates on expressions ?*Authentication-results*: sourceware.org; auth=none*References*: <CAJXstsDuzBPFUYiNv5L2n118cA8CLUPa2EPed1gCwa6PYB4C2w at mail dot gmail dot com>

On Mon, Jul 14, 2014 at 12:07 PM, Prathamesh Kulkarni <bilbotheelffriend@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 ...)). Richard. > Thanks and Regards, > Prathamesh

**Follow-Ups**:**Re: predicates on expressions ?***From:*Prathamesh Kulkarni

**Re: predicates on expressions ?***From:*Richard Biener

**References**:**predicates on expressions ?***From:*Prathamesh Kulkarni

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |