https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105740
--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 21 Jun 2022, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105740 > > --- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > The problem with switch-conversion done multiple times is that when it is done > early, it can do worse job than when it is done late, e.g. we can have better > range information later which allows (unfortunately switch-conversion doesn't > use that yet, there is a PR about it) to ignore some never reachable values > etc. > So ideally we either need to be able to undo switch-conversion and redo it if > things have changed, or do it only late and for e.g. inlining costs perform it > only in analysis mode and record somewhere what kind of lowering would be done > and how much it would cost. > With multiple if-to-switch, don't we risk that we turn some ifs into switch, > then > switch-conversion lowers it back to ifs and then another if-to-switch matches > it again and again lowers it? Yeah, I think ideally switch conversion would be done as part of switch lowering (plus maybe an extra if-to-switch). The issue might be what I said - some passes don't like switches, but they probably need to be taught. As of inline cost yes, doing likely-switch-converted analysis would probably work.
