On Wed, Sep 23, 2026 at 8:36 PM David Guillen Fandos <[email protected]> wrote: > > El mié, 23 sept 2026 a las 11:26, Richard Biener > (<[email protected]>) escribió: > > > > 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. > > I guess the symbolic number implementation could be generalized further to > track bits and bytes. Would this byte tracking also happen in these passes > or somewhere else? You can always track the bits (even if it's a bit of an > overkill) and produce byte permutation patterns (ie. like bswap). > > > > > > > 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. > > We can indeed trivially bump this to 128 and use it to track > bswapti2/bitreverseti2. I was worried that tracking so many bits would be > a performance problem but it seems it's not.
We have to be careful with stack usage when recursing though. > > > > 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 ... > > In general it might be a good idea to generalize symbolic number into > some sort of class/datatype and implement operations there (ie. bit/byte > shift, or, and, etc.) so it can be reused by any passes doing this kind of > tracking. That way we can also use uint8/uint16 depending on the number of > bits/bytes to track. Even tho I was tempted to do so, I aimed at keeping > the patches small and minimal to ensure they were easy to review (hence > why I split them this way). I was also thinking of generalizing symbolic number into some sort of class. I'll note we now have something like that with sym-exec/sym-exec-expression.h:bit_expression and friends - just to think of eventually also tracking bit/byte inversion during bswap analysis. For generic vector permutes we'd also like to track _two_ sources rather than only one ... Similarly there's the very simple bit lattice in tree-ssa-ccp.cc and the bit_value_* interfacing. Just to show the differing level of "precision" we have. Richard. > > Thanks for taking a look at the patches! > David
