[PATCH] middle-end: Fold popcount(x&4) to (x>>2)&1 and friends.

[Richard Biener]

On Mon, Jul 20, 2020 at 3:06 PM Roger Sayle <roger@nextmovesoftware.com> wrote:
>
>
> This patch complements one from June 12th which is still awaiting
> review: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547937.html
>
> This patch optimizes popcount and parity of an argument known to have
> at most a single bit set, to be that single bit.  Hence, popcount(x&8)
> is simplified to (x>>3)&1.   This generalizes the existing optimization
> of popcount(x&1) being simplified to x&1, which is moved with this
> patch to avoid a duplicate pattern warning in match.pd.
>
> This patch has been tested on x86_64-pc-linux-gnu with a "make bootstrap"
> and "make -k check" with no new failures.  If this is approved after
> (or at the same time) as the patch above, I'm happy to resolve the
> conflicts and retest before committing.

Given you know the constant bit position of the possibly nonzero
bit you can elide the conversion to unsigned for all but the case
of a possibly negative input (IIRC GCC doesn't yet take advantage
of negative right shift undefinedness - but maybe sanitizers complain).
Also the shift amount doesn't need to be in the same type as
the shifted amount so using either size_int() or integer_type_node
for that argument should reduce INTEGER_CST waste.

Any reason you are not tackling IFN_POPCOUNT/PARITY?
You could use

(for pfun (POPCOUNT PARITY)
 ...

and automagically get all builtins and the IFN.

Thanks,
Richard.



>
> 2020-07-20  Roger Sayle  <roger@nextmovesoftware.com>
>
> gcc/ChangeLog
>         * match.pd (popcount(x) -> x>>C): New simplification.
>
> gcc/testsuite
>         * gcc.dg/fold-popcount-5.c: New test.
>         * gcc.dg/fold-parity-5.c: Likewise.
>
>
> Ok for mainline?
> Thanks in advance,
> Roger
> --
> Roger Sayle
> NextMove Software
> Cambridge, UK
>