On Wed, Sep 30, 2026 at 11:49 PM David Guillen Fandos <[email protected]> wrote: > > > We have to be careful with stack usage when recursing though. > > Yeah indeed, this already uses more memory, double tracking... even more. > > > > > > > > > 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. > > Gotcha. Are we however ok with these patches for now, or do we wanna add > more stuff to them? I am happy to send more patches later to further improve > them with some of you suggestions, but don't want the patch pile to grow too > much for practical reasons :)
I wonder if it's not just more churn later when we not add some abstraction now, but that would be your call. I'll queue the actual patches for review as-is. Richard. > > Thank you!
