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.
