Re: [GSoC] user defined predicates

[Richard Biener <richard dot guenther at gmail dot com>]

On Fri, Aug 8, 2014 at 1:16 AM, Prathamesh Kulkarni
<bilbotheelffriend@gmail.com> wrote:
> Currently, we treat predicates as "second-class" citizens:
> - assume any identifier as a valid predicate
> - cannot write more complex predicates than an identifier in match-op
>
> I was wondering whether it would be a good idea
> to ave user-defined predicates,
> instead of hard-coding them as macros in gimple-match-head.c ?
>
> * Syntax
>   A predicate is assumed to expect only one operand as input.
>
> (define_predicate <name> (c_expr))
>
> and use it the same way we do currently.
>
> Example Use case:
> Consider following pattern:
> (simplify
>   (foo @0 @1)
>   (if (TYPE_UNSIGNED (TREE_TYPE (@1)))
>   @0)
>
> The second operand (@1) is only captured for sake of testing it's type
> in if-expr.
>
> Instead, define a predicate:
> (define_predicate type_unsigned_p  (TYPE_UNSIGNED (TREE_TYPE (@@)))
> @@ refers to the operand we use the predicate on.
>
> (simplify
>    (foo @0 type_unsigned)
>    @0)
>
> in this case @@ would be op21 (one of the generated temporaries during
> code-gen for match-op in decision tree).
>
> * code-gen
> We would generate predicates as macros in the generated file.
> so in gimple-match.c, there would be
> #define type_unsigned(op)  (TYPE_UNSIGNED (TREE_TYPE (op)))
> (we also need this for generic-match.c, so maybe generate macros in
> separate file say genpreds.c and include it in both gimple-match.c and
> generic-match.c)
>
> and replace @@ by correct operand in the patterns the predicates
> are used.
>
> The current "predicates" in gimple-match-head.c can be written as:
> (define_predicate INTEGER_CST_P (TREE_CODE (@@) == INTEGER_CST)))
> (define_predicate integral_op_p (INTEGRAL_TYPE_P (TREE_TYPE (@@)))
>
> Not sure if this would have real benefit, just an idea...

My line of thinking was that if there are new predicates that are useful
for writing patterns then they are useful in GCC generally and thus
should be made available in the proper generic places (not
gimple-match-head.c), like for example in tree.[ch].

Note that code-generation should be changed to delay testing of
predicates until the if-expression is processed.  That is, predicates
are really just a "shortcut" for capturing the operand and testing
the predicate in the if-expr.

The idea here is that matching the whole structure of the expression
is cheap while testing predicates is not.

So I don't think we want any define-predicate stuff in the language.

Richard.


> Thanks,
> Prathamesh