http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59920
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Eric Botcazou from comment #5) > > -g isn't needed to reproduce this. Started with r198096, the huge function > > with ~ 5000 or how many basic blocks has over 200 setjmp calls in it, so > > starting with the r198096 commit we create probably about 1000 or so more > > basic blocks, hundreds of thousands abnormal edges (but still *.cfg dump is > > emitted quickly), I think all the memory is eaten by huge PHI argument > > lists. > > It's precisely for this kind of situation that the "weirdo" (your word IIRC > :-) lowering of __builtin_setjmp was added. Maybe something similar could > be done. So perhaps a dummy internal call inserted right before the setjmp/returns_twice call and a dummy setjmp/returns_twice dispatcher and just add the AB edges? The internal call before the setjmp/returns_twice calls would have FALLTHRU edge to the setjmp/returns_twice call and AB edge to the dummy dispatcher and the dummy dispatcher would have AB edge to all the setjmp/returns_twice calls. Guess that would be enough for GIMPLE purposes, the question is what we want at RTL level. I've tried the #c0 testcase with _setjmp calls replaced with __builtin_setjmp, and while it also isn't really small IL, e.g. the __builtin_setjmp_dispatcher bb has 294 PHIs, each with 1852 args, and then each of the __builtin_setjmp_receiver blocks has those 294 PHIs with 2 args, it is far better than if we have over 200 basic blocks for _setjmp calls, each with 294 PHIs and each with 1852 arguments. That is still 100mil. PHI arguments right now vs. 600000 PHI arguments after the change.
