Re: predicates on expressions ?

[Prathamesh Kulkarni <bilbotheelffriend at gmail dot com>]

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.
For now should we go with free-form 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 ?

Thanks and Regards,
Prathamesh
>
> Richard.
>
>> Thanks and Regards,
>> Prathamesh