https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779
--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Martin Liška from comment #16) > > The old VRP/EVRP only tracks simple ranges and anti-ranges, so can't deal > > with > > what you have above, the new ranger code can deal with multiple subranges, > > but the question is if all the interfaces deal with those. > > EVRP knows the proper range: > 2->4 (F) x_6(D) : unsigned int [0, 1][4, 4] EVRP ATM invokes both the old code and ranger and only ranger knows the above. There is a param to adjust the behavior. Anyway, if something isn't able to work with the detailed ranges (up to 255 subranges), type conversions will ensure that one gets a single summary range ([0, 4] in this case likely) and possibly the switch opts still do that. Anyway, whether EVRP or VRP or whatever other pass performs some switch optimizations based on ranges or not, it is valuable to query the ranges in switchconv too. Because, what e.g. EVRP can only do with the switch is remove unreachable cases, but for switchconv it should be valueable to know for each possible value in the range of the switch index whether such value is possible and there is a handler for it and that handler is not __builtin_unreachable ();, or if the case is possible but not explicitly handled (thus default: unless default is __builtin_unreachable ()), or the never happen cases (or will invoke UB immediately, that is the same thing). Because for some things it is better to treat the last category as non-existing and for others to treat it as existing but can do anything. E.g. if you compute the full covered range, the invalid cases at the start of the range or at the end of the range don't need to be counted, one can shorten the range, but e.g. when deciding if it is contiguous or if one can use linear expressions on the index, one can treat the invalid cases as present and satisfying whatever we need.
