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 13:40:06 +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>
On Mon, May 19, 2014 at 5:51 PM, Michael Matz <email@example.com> wrote:
> On Thu, 15 May 2014, Richard Biener wrote:
>> To me predicate (and capture without expression or predicate)
>> differs from expression in that predicate is clearly a leaf of the
>> expression tree while we have to recurse into expression operands.
>> Now, if we want to support applying predicates to the midst of an
>> expression, like
>> (plus predicate(minus @0 @1)
>> then this would no longer be true. At the moment you'd write
>> (plus (minus@3 @0 @1)
>> if (predicate (@3))
>> which makes it clearer IMHO (with the decision tree building
>> you'd apply the predicates after matching the expression tree
>> anyway I suppose, so code generation would be equivalent).
> Syntaxwise I had this idea for adding generic predicates to expressions:
> (plus (minus @0 @1):predicate
So you'd write
(plus @0 :integer_zerop)
(plus @0 integer_zerop)
> 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)
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
(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)
(plus (minus @0 @1) @2)@3
so maybe apply predicates there as well:
(plus:operand_equal_p (@1, @2, 0) (minus @0 @1) @2)
But I still think that doing all predicates within a if-expr makes
the pattern less convoluted.
Enabling/disabling a whole set of patterns with a common condition
might still be a worthwhile addition.