PR middle-end/109840 is a regression introduced by my recent patch to
fold popcount(bswap(x)) as popcount(x).  When the bswap and the popcount
have the same precision, everything works fine, but this optimization also
allowed a zero-extension between the two.  The oversight is that we need
to be strict with type conversions, both to avoid accidentally changing
the argument type to popcount, and also to reflect the effects of
argument/return-value promotion in the call to bswap, so this zero extension
needs to be preserved/explicit in the optimized form.

Interestingly, match.pd should (in theory) be able to narrow calls to
popcount and parity, removing a zero-extension from its argument, but
that is an independent optimization, that needs to check IFN_ support.
Many thanks to Andrew Pinski for his help/fixes with these transformations.

This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
and make -k check, both with and without --target_board=unix{-m32}
with no new failures.  Ok for mainline?


2023-05-23  Roger Sayle  <roger@nextmovesoftware.com>

gcc/ChangeLog
        PR middle-end/109840
        * match.pd <popcount optimizations>: Preserve zero-extension when
        optimizing popcount((T)bswap(x)) and popcount((T)rotate(x,y)) as
        popcount((T)x), so the popcount's argument keeps the same type.
        <parity optimizations>:  Likewise preserve extensions when
        simplifying parity((T)bswap(x)) and parity((T)rotate(x,y)) as
        parity((T)x), so that the parity's argument type is the same.

gcc/testsuite/ChangeLog
        PR middle-end/109840
        * gcc.dg/fold-parity-8.c: New test.
        * gcc.dg/fold-popcount-11.c: Likewise.


Thanks in advance, and apologies for any inconvenience. 
Roger
--