[Bug rtl-optimization/89115] compile time and memory hog

[rguenth at gcc dot gnu.org]

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).