This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][match-and-simplify] Minor fixes to match-plusminus.pd
- From: Richard Biener <rguenther at suse dot de>
- To: Marc Glisse <marc dot glisse at inria dot fr>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 11 Sep 2014 14:43:06 +0200 (CEST)
- Subject: Re: [PATCH][match-and-simplify] Minor fixes to match-plusminus.pd
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot LSU dot 2 dot 11 dot 1409111409010 dot 20733 at zhemvz dot fhfr dot qr> <alpine dot DEB dot 2 dot 11 dot 1409111427170 dot 6431 at stedding dot saclay dot inria dot fr>
On Thu, 11 Sep 2014, Marc Glisse wrote:
> /* ~A + 1 -> -A */
> (simplify
> (plus (bit_not @0) integer_onep@1)
> (if (TREE_CODE (TREE_TYPE (@1)) != COMPLEX_TYPE
> || (TREE_CODE (@1) == COMPLEX_CST
> && integer_onep (TREE_REALPART (@1))
> && integer_onep (TREE_IMAGPART (@1))))
> (negate @0)))
>
> the complex part cannot happen, since integer_onep already checks that the
> imaginary part is 0. I was thinking of adding a predicate: integer_each_onep
> (or other name) that would be equivalent to integer_onep except for complex
> where it would check for 1+i instead of 1. We already have 2 separate
> predicates for -1 that only differ for complex. And we would probably want a
> corresponding build_ function to produce such constants.
Ah, indeed. The forwprop code reads:
else if ((TREE_CODE (TREE_TYPE (rhs2)) != COMPLEX_TYPE
&& integer_onep (rhs2))
|| (TREE_CODE (rhs2) == COMPLEX_CST
&& integer_onep (TREE_REALPART (rhs2))
&& integer_onep (TREE_IMAGPART (rhs2))))
but yes, a new predicate would be nice. In the pattern we can fix
it by using CONSTANT_CLASS_P as the predicate for @1 (or no
predicate at all).
Richard.