This is the mail archive of the 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]

[GSoC] user defined predicates

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:
  (foo @0 @1)

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.

   (foo @0 type_unsigned)

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

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...


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]