On Mon, Jul 14, 2014 at 12:07 PM, Prathamesh Kulkarni
<bilbotheelffri...@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
