[Bug c++/55135] [4.8 Regression] Segfault of gcc on a big file

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55135

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> 2013-03-01 10:44:10 UTC ---
(In reply to comment #10)
> Created attachment 29557 [details]
> Collected hacks to make the test case compile in reasonable time with -O0
> 
> Patch does 2 things:
> 
> - Queue up to-be-removed EH regions, instead of removing them one-by-one.
>   Removing them one at a time results in walking the list of EH regions
>   repeatedly, thus taking O(# of EH regions ** 2) time.

This (properly cleaned up) looks reasonable to me.

> - Rewrite init_subregs_of_mode and subroutines to first collect the
>   invalid mode change subregs in sbitmaps, and then converting the final
>   sbitmap to a bitmap. This trades memory for time: the bitmap lookups are
>   also potentially O(# of registers ** 2) and this test case has more than
>   one million registers, many of them with invalid mode changes (to be fixed
>   up by IRA/LRA).

Hmm - this is because we hit the O(n) complexity we have on our bitmap
implementation?  Can't we improve init_subregs_of_mode by first collecting
all mode changes we see for a pseudo (eventually using DF info?) and
then do the processing in some more optimal order?

Trading memory O(number of pseudos) with a large constant factor sounds
like something waiting for trouble for other testcases ...

> Peak memory at -O0 is <4GB. Compile time on a "Quad-Core AMD Opteron(tm)
> Processor 8354" at 2200MHz is 240s, half of it still taken up by IRA+LRA.
> 
> At -O1 the einline pass is consuming almost all compile time again.
> -> Honza: Can we please have a proper permanent fix for this recurring
> problem? What's there now just Does Not Work!