This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]