https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117964
--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 10 Dec 2024, segher at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117964 > > --- Comment #7 from Segher Boessenkool <segher at gcc dot gnu.org> --- > When maybe_duplicate_computed_goto is asked to duplicate a block with 9189 > successors, it damn well should! If that is a bad idea for the case at hand, > just do not call maybe_duplicate_computed_goto on such a block! > > maybe_duplicate_computed_goto should never ever decide to know better than > its caller. That way insanity lies. "maybe_" suggests it's not all that clear, I understand the intent is more like duplicate_computed_goto_if_possible (as opposed to _if_profitable_and_possible). But sure, limiting in the caller is sensible as well - it might be even applying an overall cost (rather than a per PRED duplication cost). But as said the main issue is the successors are "artificial" - there's only a single real successor - it's just not known statically. So finding a better representation for the CFG to solve the time/memory issue is better than not duplicating the gotos.
