[Bug other/59920] [4.9 Regression] build doesn't terminate (at least after an hour)

jakub at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Fri Jan 24 19:56:00 GMT 2014


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.



More information about the Gcc-bugs mailing list