On Tue, May 20, 2014 at 2:20 PM, Michael Matz <m...@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.
