[Bug middle-end/56719] missed optimization: i > 0xffff || i*4 > 0xffff

[jakub at gcc dot gnu.org]

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.