On Wed, Sep 23, 2026 at 11:17 AM Jakub Jelinek <[email protected]> wrote: > > On Wed, Sep 23, 2026 at 10:59:58AM +0200, Richard Biener wrote: > > On Wed, Sep 23, 2026 at 12:37 AM David Guillen Fandos <[email protected]> > > wrote: > > > These patches aim to expand and improve the byte swapping pass to > > > recognize > > > some more patterns including bit reverse patterns. The first three > > > patches > > > build on bswap to track bits instead of bytes and recognize some new bswap > > > patterns (ie. with somewhat arbitrary rotation and masking). The last > > > three > > > add bitreverse recognition including 8 and 16 bit variants. > > > > Thanks for improving the symbolic number tracking. One thing that's on my > > wish list for this is tracking of vector lane permutations and vector > > per-element > > shifts/masks with the idea to detect permutes. That would require tracking > > larger symbolic numbers (for AVX512 it's 512 bits), but bit tracking is > > overkill > > there. So I wonder how ugly it gets to make bits vs. bytes configurable? > > As you've transitioned bytes to bits you can probably answer this quickly. > > Also, if we change the tracking representation, we should also start > supporting __int128, so don't limit to 64 bits, but 128. Even when no > target actually supports bswapti2 or bitreverseti2, those can be implemented > using 2 bswapdi2 or bitreversedi2. > Except for vectors, we don't need to support more than 128 bits I think, > large/huge _BitInt should be lowered by the time this pass runs.
Note with AVX512 there's the additional issue that a uint8_t is not enough to track the bit position. Even AVX2 (256 bits) leaves no bit left for "unknown" or "known zero". Thus my ask for the ability to also track at byte granularity ... Richard. > > Jakub >
