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: [GSoC] writing test-case


On Tue, May 20, 2014 at 2:20 PM, Michael Matz <matz@suse.de> wrote:
> Hi,
>
> On Tue, 20 May 2014, Richard Biener wrote:
>
>> > Syntaxwise I had this idea for adding generic predicates to expressions:
>> >
>> > (plus (minus @0 @1):predicate
>> >       @2)
>> > (...)
>>
>> So you'd write
>>
>>  (plus @0 :integer_zerop)
>>
>> instead of
>>
>>  (plus @0 integer_zerop)
>>
>> ?
>
> plus is binary, where is your @1?

I know it's zero so I don't need it captured.

(match_and_simplify
   (plus @0 integer_zerop)
   @0)

mind that all predicates apply to leafs only at the moment.

>  If you want to not capture the second
> operand but still have it tested for a predicates, then yes, the first
> form it would be.

Ok.

>>
>> > If prefix or suffix doesn't matter much, but using a different syntax
>> > to separate expression from predicate seems to make things clearer.
>> > Optionally adding things like and/or for predicates might also make sense:
>> >
>> > (plus (minus @0 @1):positive_p(@0) || positive_p(@1)
>> >       @2)
>> > (...)
>>
>> negation whould be more useful I guess.  You open up a can of
>> worms with ordering though:
>>
>> (plus (minus @0 @1) @2:operand_equal_p (@1, @2, 0))
>>
>> which might be declared invalid or is equivalent to
>
> It wouldn't necessarily be invalid, the predicate would apply to @2;
> but check operands 1 and 0 as well, which might be surprising.  In this
> case it might indeed be equivalent to :
>
>> (plus (minus @0 @1) @2):operand_equal_p (@1, @2, 0)
>
>
>
>> Note that your predicate placement doesn't match placement of
>> captures for non-innermost expressions.  capturing the outer
>> plus would be
>>
>> (plus@3 (minus @0 @1) @2)
>
>
> You're right, I'd allow placing the predicate directly behind the capture,
> i.e.:
>
> (plus@3:predicate (minus @0 @1) @2)
>
>> But I still think that doing all predicates within a if-expr makes the
>> pattern less convoluted.
>
> I think it simply depends on the scope of the predicate.  If it's a
> predicate applying to multiple operands from different nested level an
> if-expr is clearer (IMHO).  If it applies to one operand it seems more
> natural to place it directly next to that operand.  I.e.:
>
> (minus @0 @1:non_negative)             // better
>
> vs.
>
> (minus @0 @1)
>   (if (non_negative (@1))
>
> But:
>
> (plus@3 (minus @0 @1) @2)              // better
>   (if (operand_equal_p (@1, @2, 0))
>
> vs:
>
> (plus@3:operand_equal_p (@1, @2, 0) (minus @0 @1) @2)
>
> That is we could require that predicates that are applied with ':' need to
> be unary and apply to the one expression to which they are bound.

Your example is to leafs which we already support as

(minus @0 non_negative@1)

any good example that is not convoluted where that applies to a
non-leaf position?

>> Enabling/disabling a whole set of patterns with a common condition
>> might still be a worthwhile addition.
>
> Right, but that seems orthogonal to the above?

Right.

Richard.

>
> Ciao,
> Michael.


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