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*: Tue, 15 Jul 2014 10:37:46 +0200*Subject*: Re: predicates on expressions ?*Authentication-results*: sourceware.org; auth=none*References*: <CAJXstsDuzBPFUYiNv5L2n118cA8CLUPa2EPed1gCwa6PYB4C2w at mail dot gmail dot com> <CAFiYyc2imdRW4oCieE3Caxk7=+j=aruGCqD0E2VQUyY==FxGBA at mail dot gmail dot com> <CAJXstsA_c2d7+6SemZNiuFX0BgVVe2vzVpYv5iWOG2NMRNkLkA at mail dot gmail dot com>

On Mon, Jul 14, 2014 at 10:52 PM, Prathamesh Kulkarni <bilbotheelffriend@gmail.com> wrote: > On Mon, Jul 14, 2014 at 6:35 PM, Richard Biener > <richard.guenther@gmail.com> wrote: >> 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 ...)). > 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

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

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

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

**Re: 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] |