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]

Re: predicates on expressions ?


On Tue, Jul 15, 2014 at 2:07 PM, Richard Biener
<richard.guenther@gmail.com> wrote:
> 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.
maybe use braces ?
if (c_expr)
{
   patterns
}
but (if ...) is better.
>
>> 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.
Okay.
>
> 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.
Um, I don't get this.
say we have the following pattern:
(if cond
   (match_and_simplify
    match1
    transform1)

   (match_and_simplify
    match2
    transform2))

The generated code would be the following ?
if (cond)
{
   match1
      transform1

   match2
      transform2
}

Currently we do:
match1
  if (cond)
    transform1

match2
  if (cond)
    transform2

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


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