http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56719
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-03-25 15:25:53 UTC --- This actually isn't about optimizing away the first compare, but about merging the two conditions into one that is equivalent to those two ored together. The first condition is for range of i [0x10000U, 0xffffffffU] while the latter for ranges [0x4000U, 0x3fffffffU] or [0x40004000U, 0x7fffffffU] or [0x80004000U, 0xbfffffffU] or [0xc0004000U, 0xfffffffU], and all the 5 ranges together are [0x4000U, 0xffffffffU]. Perhaps optimize_range_tests (or its fold-const.c counterpart) could both do it, but the really ugly thing is that either we'd need to expand i*4 into 4 range tests and teach the code that those 4 are really already represented by one range tests and thus an optimization would be only if we can even fewer range tests than that (with some cap on number of ranges we'd generate, like 8-16 or so), or have some way to mark some range fuzzy (i.e. in that range we don't know if it is in the range or out of it), and represent i*4 > 0xffffU as [0x4000, 0x3fffffffU] range ored with fuzzy range [0x40004000U, 0xffffffffU]. Fuzzy range would then be treated for | as only optimizable if other non-fuzzy ranges together completely cover that range (and for & that non-fuzzy ranges anded together don't cover any of the values in the fuzzy range). Anyway, I agree with Richard that it is questionable how often this would actually hit in real-world code, i.e. whether this really is something to spend lots of work on.
