This is the mail archive of the
mailing list for the GCC project.
Re: [GSoC] writing test-case
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Michael Matz <matz at suse dot de>
- Cc: Prathamesh Kulkarni <bilbotheelffriend at gmail dot com>, Andreas Schwab <schwab at linux-m68k dot org>, Diego Novillo <dnovillo at google dot com>, gcc <gcc at gcc dot gnu dot org>, Maxim Kuvyrkov <maxim dot kuvyrkov at linaro dot org>
- Date: Tue, 20 May 2014 15:13:32 +0200
- Subject: Re: [GSoC] writing test-case
- Authentication-results: sourceware.org; auth=none
- References: <CAJXstsAsui9S5q2Q0VxUjnrtgvbgd+W_cxcZqXG-p5dEqpNnEQ at mail dot gmail dot com> <878uq8idjw dot fsf at igel dot home> <CAJXstsCeKwRe7eQRiwyoDKr9h7KVy7MfMLmjOne2WBH6iqcMJg at mail dot gmail dot com> <CAFiYyc1KZaBcPzRifDtsQb0_wDPx_8qBbnR5C8ByVfPucyryoQ at mail dot gmail dot com> <CAJXstsCBduFryPA-xe8mwM_q2keNX9B4XtXLSkFNKmL=rWRoFQ at mail dot gmail dot com> <CAFiYyc3R+OAyeEZYpY1ekv=gN0CbLp9XaYJ+WZtpLzavKmzKDQ at mail dot gmail dot com> <CAFiYyc1O_CQXegp1b03LHungMpv_tSnAj1EEwuQ6DCXRPyoP7w at mail dot gmail dot com> <CAFiYyc0SAicvNNaBb1Gt0n=pFW1Hgr-BT3vuw9GYOcr8C716bg at mail dot gmail dot com> <CAJXstsBi_Fb5cWf5nNGkJoN4xjycDp_oc3C7Fdhs2jA6ffK=sQ at mail dot gmail dot com> <CAFiYyc2+n73QNhGL0+KwFK9pCOGz-F=x88c+5Dgp5zZWdO0dWw at mail dot gmail dot com> <alpine dot LNX dot 2 dot 00 dot 1405191746220 dot 23942 at wotan dot suse dot de> <CAFiYyc2GwJ-imMbuM5_QnJwm2SgW+JzEzwH9myrU-YHYVhgzCw at mail dot gmail dot com> <alpine dot LNX dot 2 dot 00 dot 1405201409160 dot 23942 at wotan dot suse dot de>
On Tue, May 20, 2014 at 2:20 PM, Michael Matz <email@example.com> wrote:
> 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.
(plus @0 integer_zerop)
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.
>> > 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,
> (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
> (minus @0 @1)
> (if (non_negative (@1))
> (plus@3 (minus @0 @1) @2) // better
> (if (operand_equal_p (@1, @2, 0))
> (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
>> 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?