On Tue, May 23, 2023 at 8:30 PM Roger Sayle <ro...@nextmovesoftware.com> wrote:
>
>
> 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?
OK.
Thanks,
Richard.
>
> 2023-05-23 Roger Sayle <ro...@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
> --
>
