On Fri, 2020-08-21 at 17:52 +0100, Roger Sayle wrote: > This simple patch to match.pd optimizes away bit permutation > operations, specifically bswap and rotate, in calls to popcount and > parity. Although this patch has been developed and tested on LP64, > it relies on there being no truncations or extensions to "marry up" > the appropriate PARITY, PARITYL and PARITYLL forms with either BSWAP32 > or BSWAP64, assuming this transformation won't fire if the integral > types have different sizes. > > The following patch has been tested on x86_64-pc-linux-gnu with > "make bootstrap" and "make -k check" with no new failures. > Ok for mainline? > > 2020-08-21 Roger Sayle <ro...@nextmovesoftware.com> > > gcc/ChangeLog > * gcc/match.pd (popcount(bswapN(x)) -> popcount(x), > popcount(rotate(x)) -> popcount(x), parity(bswapN(x)) -> parity(x), > parity(rotate(x)) -> parity(x)): New simplifications. > > gcc/testsuite/ChangeLog > * gcc.dg/fold-popcount-6.c: New test. > * gcc.dg/fold-popcount-7.c: New test. > * gcc.dg/fold-parity-6.c: New test. > * gcc.dg/fold-parity-7.c: New test. My worry here would be GCC's habit of not type checking arguments to builtins all that well. It's come up several times recently and while I think some of those holes have been closed, I don't have much confidence we're doing a good job there.
So with that in mind, this is fine if you verify that the type of the argument is the same as the resultant type. I think you've got access to both within the match.pd framework. jeff >
