This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Add (x & ~m) | (y & m) folding (PR middle-end/63568)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Marek Polacek <polacek at redhat dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Richard Biener <rguenther at suse dot de>
- Date: Wed, 17 Dec 2014 10:04:53 +0100
- Subject: Re: [PATCH] Add (x & ~m) | (y & m) folding (PR middle-end/63568)
- Authentication-results: sourceware.org; auth=none
- References: <20141217084644 dot GJ16332 at redhat dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Wed, Dec 17, 2014 at 09:46:44AM +0100, Marek Polacek wrote:
> This adds a transformation of (x & ~m) | (y & m), which (on GIMPLE)
> has 4 ops to x ^ ((x ^ y) & m) that has 3 ops on GIMPLE. In fact,
> the latter is then transformed to (a ^ b) & m ^ a, which also has 3
> ops.
So why don't you transform it to ((x ^ y) & m) ^ x directly (i.e. swap
@0 with the (bit_and ...) ?
BTW, the advantage of (x & ~m) | (y & m) form is that there are fewer
dependencies, at least if the target has andn instruction (e.g. SPARC,
Alpha, PA, MMIX, IA64 have them), just the final or depends on the result of
both and and andnot instructions. While in the 2 xor forms, and
depends on the first xor result and the second xor depends on the and
result, so if there are multiple ALU units available, the and | andn
form can use both the units, while the second one is unnecessarily
serialized.
Jakub