Re: [GSoC] writing test-case

[Michael Matz <matz at suse dot de>]

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

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

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


Ciao,
Michael.