This is the mail archive of the
mailing list for the GCC project.
Re: match.pd: Optimize (x & y) ^ (x | y)
- From: Marek Polacek <polacek at redhat dot com>
- To: Marc Glisse <marc dot glisse at inria dot fr>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Richard Biener <rguenther at suse dot de>
- Date: Thu, 11 Jun 2015 18:12:30 +0200
- Subject: Re: match.pd: Optimize (x & y) ^ (x | y)
- Authentication-results: sourceware.org; auth=none
- References: <20150611110432 dot GY2756 at redhat dot com> <alpine dot DEB dot 2 dot 20 dot 1506111717100 dot 8389 at stedding dot saclay dot inria dot fr>
On Thu, Jun 11, 2015 at 05:25:30PM +0200, Marc Glisse wrote:
> On Thu, 11 Jun 2015, Marek Polacek wrote:
> >I have verified this transformation on a toy testcase (tried x and y
> >in the range [-1000,1000]) and it does a correct thing for all integers.
> Note that for pure bitop (only involving &|^), testing the range [0,1] is
I'd feel safer when testing a wider range of integers ;).
> >+/* (x & y) ^ (x | y) -> x ^ y */
> >+ (bit_xor:c (bit_and@2 @0 @1) (bit_ior@3 @0 @1))
> Make either bit_and or bit_ior commutative? Or do we canonicalize in a way
> that makes it unnecessary?
Correct: bit_and and bit_ior don't need :c here. (But the bit_xor needs it.)
I've tried various ordering of x and y and all of them were optimized.
Arguably I should've put more tests into the testcase...
> >+ (if (single_use (@2) && single_use (@3))
> >+ (bit_xor @0 @1)))
> I don't think we should use single_use here. The result is never more
> complicated than the original. Sure, it might increase register pressure a
> bit in some cases, but we have not used that as a criterion for other
> simplifications in match.pd yet (LLVM does though).
I don't have a strong preference here but we surely use single_use
in match.pd elsewhere.