|
|
Jan Hubicka wrote:
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?
I saw some functions which could have slowed down regional IRA a lot.
For example, a small function with 50 loops one after another.
Therefore IRA has already code (decreasing # of regions/loops for
consideration) to deal with the situation.
The worst what I saw a few years ago. One customer system generated
functions with 100K blocks and >1M pseudos. But fortunately they
started to split the code into several functions.
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 ;)
|
|