This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Fold VEC_COND_EXPRs to IFN_COND_* where possible
- From: Richard Sandiford <richard dot sandiford at linaro dot org>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 24 May 2018 13:21:03 +0100
- Subject: Re: Fold VEC_COND_EXPRs to IFN_COND_* where possible
- References: <874lixe87r.fsf@linaro.org> <CAFiYyc39MywA6_7CbCaGfOiOw2yh4517=Y==scbn+77oS1c=mw@mail.gmail.com>
Richard Biener <richard.guenther@gmail.com> writes:
>> 2018-05-24 Richard Sandiford <richard.sandiford@linaro.org>
>
>> gcc/
>> * doc/sourcebuild.texi (vect_double_cond_arith: Document.
>> * gimple-match.h (gimple_match_op::MAX_NUM_OPS): Bump to 4.
>> (gimple_match_op::gimple_match_op): Add an overload for 4
> operands.
>> (gimple_match_op::set_op): Likewise.
>> (gimple_resimplify4): Declare.
>> * genmatch.c (commutative_op): Handle CFN_COND_* functions.
>
> ^^^ you don't seem to use that and I don't see how those are commutative
> in operands 1 and 2 without inverting operand 0. So w/o adjusting the
> parsing part I think that people can write (cond_foo:c ...) and likely
> be surprised that it isn't rejected. It is of course required to make :C
> work.
Operands 1 and 2 are the operands of the binary operation, and now
that the else value is specified separately, the functions are
commutative in those operands if the binary operation is commutative.
Of course, CFN_COND_SUB shouldn't have been there, sigh...
> The patch is ok if you drop this hunk for now. You can re-introduce it
> as followup if you make sure to make :c error on those IFNs.
OK, thanks. I'm happy to drop it for now.
Richard