https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89115
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |compile-time-hog,
| |memory-hog, ra
Status|UNCONFIRMED |NEW
Last reconfirmed| |2019-01-30
CC| |vmakarov at gcc dot gnu.org
Ever confirmed|0 |1
Known to fail| |8.2.1, 9.0
--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
On x86_64-linux:
> /usr/bin/time gcc-8 -S tagCircle49h12.i
38.02user 0.19system 0:38.22elapsed 99%CPU (0avgtext+0avgdata
547252maxresident)k
0inputs+14440outputs (0major+157121minor)pagefaults 0swaps
> /usr/bin/time gcc-8 -S tagCircle49h12.i -O
49.24user 0.99system 0:50.23elapsed 99%CPU (0avgtext+0avgdata
3801468maxresident)k
320inputs+9808outputs (3major+962644minor)pagefaults 0swaps
> /usr/bin/time gcc-8 -S tagCircle49h12.i -O2
76.06user 0.17system 1:16.24elapsed 99%CPU (0avgtext+0avgdata
494480maxresident)k
0inputs+7280outputs (0major+140687minor)pagefaults 0swaps
there's a big function initializing an array which is the culprit:
__attribute__((visibility("default")))
apriltag_family_t *tagCircle49h12_create()
{
apriltag_family_t *tf = calloc(1, sizeof(apriltag_family_t));
tf->name = strdup("tagCircle49h12");
tf->h = 12;
tf->ncodes = 65698;
tf->codes = calloc(65698, sizeof(uint64_t));
tf->codes[0] = 0x0000c6c921d8614aUL;
...
tf->codes[65697] = 0x000092506b5ec3aaUL;
tf->nbits = 49;
...
during it's compile we build up a lot of garbage as well:
Assembling functions:
<materialize-all-clones> <simdclone> tagCircle49h12_create {GC 3275766k ->
118073k} tagCircle49h12_destroy
Time variable usr sys wall
GGC
dead store elim1 : 9.38 ( 19%) 0.74 ( 33%) 10.12 ( 20%)
3048002 kB ( 88%)
LRA reload inheritance : 32.58 ( 66%) 0.00 ( 0%) 32.60 ( 63%)
0 kB ( 0%)
TOTAL : 49.57 2.27 51.85
3446647 kB
Maybe we can disable
reload inheritance with some limit, at least at -O1 (which is what we intend
to "support" for insane testcases). Vlad?
On trunk we have (with detailed-mem-stats and release checking):
dead store elim1 : 44.34 ( 49%) 6.42 ( 76%) 50.76 ( 51%)
3048002 kB ( 89%)
LRA reload inheritance : 32.51 ( 36%) 0.00 ( 0%) 32.51 ( 33%)
0 kB ( 0%)
Looks like there's no -fno-lra-inheritance but "not doing" is supported
as seen by existence of LRA_MAX_INHERITANCE_PASSES (hard defined to 2
rather than a --param or conditional on optimize level).
All of the memory goes here:
explow.c:198 (plus_constant) 3025M: 95.8% 0 :
0.0% 72 : 0.0% 0 : 0.0% 126M
(not very informative, might also be a sign of a target[hook] issue).
