As usual, thanks for doing all this. *blush*
Aldy On Tue, May 13, 2025 at 2:15 AM Andrew MacLeod <amacl...@redhat.com> wrote: > When there are trailing 0's in the bitmask, I previously modified > set_range_from_bitmask () to remove the lower positive ranges which do > not match the value to help with some optimizations. It helps with > lower range comparisons and generally seemed to be a good thing. > > This reworks it clean it up a bit and also provide the same > functionality for the negative ranges of signed types using those bits. > > The original version also didn't properly return true or false based on > whether the range changed or not. This one does. > > ie, If the lower 4 bits are all 0: > int [-INF, +INF] MASK 0xfffffff0 VALUE 0x0 > > currently becomes: > int [-INF, 0][16, 2147483632] MASK 0xfffffff0 VALUE 0x0 > > and with this patch it is enhanced to also remove those negative values > and is now: > int [-INF, -16][0, 0][16, 2147483632] MASK 0xfffffff0 VALUE 0x0 > > The test case I included with the patch goes all the way through > optimization and never removed the call to dead. It might be somewhat > artificial, but you never know where these things will show up after > masking and casting. > > Oh, and the change to tree-ssanames.cc is because, as you can see, a > range with masks can require 3 ranges... and set_bitmask was using an > int_range<2>, which caused some havoc with one of the existing testcases > when we were expecting more precision, and 2 sub-ranges wasn't cutting > it if we happen to choose the wrong pair to combine/form. > > bootstraps on x86_64-pc-linux-gnu with no regressions. Pushed. > > Andrew > > >
