> 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 :) Thank you!
