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. > > 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). Thanks for taking a look at the patches! David
