https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89059
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> --- It is way too early, but on the other side the inlining decisions want to know if the switch is optimizable in certain way. So one possibility would be to lower as we currently do, but add optimizations to simplify and/or convert to some other form later after IPA. And another would be to just do the analysis phase of switches shortly before inlining and note (either in flags on GIMPLE_SWITCH or in an on-the-side data structure or whatever) what way we'd optimize the switch, take it into account during inlining cost computations and lower for real after IPA only. Though, e.g. if we decide to go with a value table for a switch in an inline function and if in all the inline copies we still decide to use the same value table, it would be nice to share the tables. But, if in each inlined copy VRP has different ranges and we can build different tables, we shouldn't share them... And there is another PR that we should use range info (ranger at this point) in the switch lowering decisions.
