https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94779
--- Comment #22 from Andrew Macleod <amacleod at redhat dot com> --- (In reply to Martin Liška from comment #21) > > See my comment above. It isn't any integration of VRP, just asking the > > ranger about the range, and it isn't useless because to be able to optimize > > properly, > > you need to figure out for each value one of the 3 possibilities (handled > > explicitly by switch and well defined, handled by default and never > > reachable or UB). > > I've got the point that we have these 3 possibilities for each case. > However, we also have it for "holes" which are removed and we can't > distinguish > them in between __builtin_unreachable and falling to the default case. > > I believe a better place for Ranger is to improve: > simplify_using_ranges::simplify_switch_using_ranges (gswitch *stmt) Long term, my goal is to decentralize this sort of thing. This routine a is legacy approach from when VRP needed to be a mini-optimizer because it was the only place reasonable range information was available. I would to push virtually everything from VRP into more appropriate places. folding, simplification, threading, switch rewriting, etc can all be done either in a specialized pass of their own, or ongoing as other related things are happening. Switch simplification/optimization in particular is a good candidate. A self contained pass that knows what best to do with a switch, and can utilize accurate range info can take care of everything with a deep analysis. It could be invoked in multiple places if required. Then you don't need to worry about a pass like VRP or some other pass messing up the structure of the switch. I would like to see the simplification routines completely moved into a switch optimization pass, and VRP would then just ignore switches.
