https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125571
Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ebotcazou at gcc dot gnu.org
--- Comment #16 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> At -O1 we have, besides SSA rewrite
>
> tree SSA rewrite : 286.87 ( 72%) 32M ( 4%)
> tree FRE : 72.03 ( 18%) 10M ( 1%)
> TOTAL : 399.91 730M
> 398.93user 0.78system 6:40.00elapsed 99%CPU (0avgtext+0avgdata
> 1343812maxresident)k
> 4888inputs+0outputs (21major+395814minor)pagefaults 0swaps
>
> I think it's worth recognizing this as a bug despite "non-optimal" source
> form. At least at -O0 and -O1 (at -O0 also with -g added).
I would not waste any time trying to optimize such an abomination, it's usually
hopeless; the optimization should be performed upstream instead. But I agree
that behaving decently at -O0 is a sensible goal.
> The complexity arises because of how we ensure correctness with setjmp
> by using abnormal edges which blows up the number of edges and, with
> a large number of BBs with setjmp we'll have the abnormal dispatcher
> as a block with very high in- and out degree.
Without abnormal dispatcher, the blow-up would be even bigger in the general
case, although it may indeed be counter-productive in specific cases.
