Re: Whole program optimization and functions-only-called-once.

[Jan Hubicka <hubicka at ucw dot cz>]

> Toon Moene wrote:
>
>> Jan Hubicka wrote:
>
>>> :) It would be nice to know what caused the OOM.  Is just one of  
>>> passes exploding
>>> on presence of very large bodies?
>>
>> I'll try to figure this out over the weekend (sorry, don't have more  
>> spare time).
>>
>> It's most probably a single pass, because the memory requirements kept  
>> creeping up to 12.5 Gbytes from 10, slowly increasing all the time over 
>> several minutes.
>
> Here are the tracebacks from gdb attached to the lto1 process, while it  
> was expanding from 7 to 12 Gb:

Hopefully Vladimir will know answer here.  Do you have any idea how many BBs
and loops are in the large function?

>From inliner POV, all I can do is to ask you about size estimate of it (that is
in the -fdump-ipa-inline dump) and adjust large-function-insns and
large-function-growth parameters to outlaw whatever inlining happens there if
there is really no better way to cure this.

This is first time I see explossion in loop related code, it might be also
possible to trottle inliner about size of loop structure, but that might be bad
idea - it is usually good to produce huge loop trees if they appear in program
for LNO (that we don't really have and graphite is exponential here too, so who
knows ;)

> #3  0x000000000099d8c0 in get_loop_body (loop=0x2b966e38ecf0) at  
> ../../gcc/gcc/cfgloop.c:819
> #4  0x000000000099e14c in get_loop_exit_edges (loop=0x2b966e38ecf0) at  
> ../../gcc/gcc/cfgloop.c:1157
> #5  0x0000000000530632 in create_loop_tree_nodes (loops_p=1 '\001') at  
> ../../gcc/gcc/ira-build.c:155

Looking at the implementation of get_loop_exit_edges, probably we would be more
effecient here if IRA built loop structure with LOOPS_HAVE_RECORDED_EXITS.
There seems to be couple places where IRA is looking for loop exists.

Honza