[Bug tree-optimization/54488] tree loop invariant motion uses an excessive amount of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54488 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- On x86_64-linux I still see 1GB used (watching top) on the 4.9 branch at -O1 and compilation takes about 8 minutes. Note that your compiler has checking enabled which at least makes the -ftime-report output unreliable. -O2 is not expected to deal very well with such large testcases (of course improving here is nice). LIM performs more expensive alias analysis at -O2 which may distort numbers here (to the worse, I don't expect that to improve things). I have now verified that on trunk and the 4.9 branch it is not LIM anymore that uses memory / compile-time. Thus this issue is fixed.
[Bug tree-optimization/54488] tree loop invariant motion uses an excessive amount of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54488 --- Comment #9 from Evgeniya Maenkova evgeniya.maenkova at gmail dot com --- I use 32bit Linux, perhaps, that gives the difference. Regarding checking and O2 - I will read about this. Thanks for your note.
[Bug tree-optimization/54488] tree loop invariant motion uses an excessive amount of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54488 --- Comment #6 from rguenther at suse dot de rguenther at suse dot de --- On Sun, 19 Oct 2014, evgeniya.maenkova at gmail dot com wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54488 --- Comment #5 from Evgeniya Maenkova evgeniya.maenkova at gmail dot com --- Also, I collect massif data and see no tree-ssa-lim in it (i mean in top contributors). So what do you think? (How did you measured 1,8Gb caused by lim? - this is for me to understand whether this bug is actual or not) I basically watched 'top' with breakpoints at the start and end of LIM.
[Bug tree-optimization/54488] tree loop invariant motion uses an excessive amount of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54488 --- Comment #7 from Evgeniya Maenkova evgeniya.maenkova at gmail dot com --- I got only 317Mb by top.
[Bug tree-optimization/54488] tree loop invariant motion uses an excessive amount of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54488 --- Comment #3 from Evgeniya Maenkova evgeniya.maenkova at gmail dot com --- Could you please clarify your comment #36 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590#c36) in PR4596? I mean LIM is now the pass that pushes memory usage to 1.8GB - all other optimization passes are happy with just ~800MB. How did you measure lim impact (1,8G)? (Was it by -ftime-report being run with/without lim optimization? Or was it top? Or some other tool which allow to see memory footprint for each optimization pass.) I can see this (for the full test case om 46590). ( I mean based on -ftime-report we see ~5,5Mb, but this only GC memory, right? ): MAIN__ main Analyzing compilation unit {GC 41969k - 36104k} {GC 72488k - 52189k} {GC 70118k - 55388k}Performing interprocedural optimizations *free_lang_data visibility early_local_cleanups {GC 81054k - 73552k} free-inline-summary whole-program profile_estimate devirt cp inline pure-const static-var single-use comdatsAssembling functions: MAIN__ {GC 137793k - 78714k} {GC 107079k - 70685k} {GC 97203k - 77229k} {GC 100487k - 71679k} {GC 148921k - 129443k} {GC 190666k - 128409k} {GC 168488k - 127341k} main Execution times (seconds) phase setup : 0.05 ( 0%) usr 0.01 ( 0%) sys 0.08 ( 0%) wall 107 kB ( 0%) ggc phase parsing : 13.79 ( 1%) usr 0.15 ( 0%) sys 13.94 ( 1%) wall 41869 kB ( 7%) ggc phase lang. deferred: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 0 kB ( 0%) ggc phase opt and generate :2103.63 (99%) usr 89.40 (100%) sys2195.36 (99%) wall 519770 kB (93%) ggc phase finalize : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc garbage collection : 5.42 ( 0%) usr 0.04 ( 0%) sys 5.48 ( 0%) wall 0 kB ( 0%) ggc callgraph construction : 0.91 ( 0%) usr 0.00 ( 0%) sys 0.88 ( 0%) wall 7644 kB ( 1%) ggc callgraph optimization : 0.12 ( 0%) usr 0.00 ( 0%) sys 0.13 ( 0%) wall 0 kB ( 0%) ggc ipa dead code removal : 0.04 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 0 kB ( 0%) ggc ipa cp : 0.18 ( 0%) usr 0.00 ( 0%) sys 0.19 ( 0%) wall 256 kB ( 0%) ggc ipa inlining heuristics : 2.54 ( 0%) usr 0.00 ( 0%) sys 2.54 ( 0%) wall 3253 kB ( 1%) ggc ipa profile : 0.27 ( 0%) usr 0.00 ( 0%) sys 0.27 ( 0%) wall 0 kB ( 0%) ggc ipa pure const : 0.42 ( 0%) usr 0.00 ( 0%) sys 0.42 ( 0%) wall 0 kB ( 0%) ggc cfg construction: 0.31 ( 0%) usr 0.01 ( 0%) sys 0.33 ( 0%) wall 2278 kB ( 0%) ggc cfg cleanup : 1.75 ( 0%) usr 0.05 ( 0%) sys 1.90 ( 0%) wall 752 kB ( 0%) ggc CFG verifier: 22.85 ( 1%) usr 0.10 ( 0%) sys 22.83 ( 1%) wall 0 kB ( 0%) ggc trivially dead code : 1.12 ( 0%) usr 0.00 ( 0%) sys 1.10 ( 0%) wall 0 kB ( 0%) ggc df scan insns : 2.79 ( 0%) usr 0.12 ( 0%) sys 2.92 ( 0%) wall 0 kB ( 0%) ggc df multiple defs: 0.75 ( 0%) usr 0.01 ( 0%) sys 0.77 ( 0%) wall 0 kB ( 0%) ggc df reaching defs: 76.35 ( 4%) usr 68.69 (77%) sys 144.67 ( 7%) wall 0 kB ( 0%) ggc df live regs: 6.93 ( 0%) usr 0.79 ( 1%) sys 7.65 ( 0%) wall 0 kB ( 0%) ggc df liveinitialized regs: 2.74 ( 0%) usr 0.69 ( 1%) sys 3.41 ( 0%) wall 0 kB ( 0%) ggc df use-def / def-use chains: 1.04 ( 0%) usr 0.00 ( 0%) sys 1.10 ( 0%) wall 0 kB ( 0%) ggc df reg dead/unused notes: 4.37 ( 0%) usr 0.00 ( 0%) sys 4.36 ( 0%) wall 6401 kB ( 1%) ggc register information: 0.56 ( 0%) usr 0.00 ( 0%) sys 0.55 ( 0%) wall 0 kB ( 0%) ggc alias analysis : 3.12 ( 0%) usr 0.00 ( 0%) sys 3.15 ( 0%) wall 9226 kB ( 2%) ggc alias stmt walking : 632.31 (30%) usr 2.05 ( 2%) sys 635.16 (29%) wall 2380 kB ( 0%) ggc register scan : 0.21 ( 0%) usr 0.00 ( 0%) sys 0.21 ( 0%) wall 274 kB ( 0%) ggc rebuild jump labels : 0.54 ( 0%) usr 0.01 ( 0%) sys 0.54 ( 0%) wall 0 kB ( 0%) ggc parser (global) : 13.79 ( 1%) usr 0.15 ( 0%) sys 13.94 ( 1%) wall 41869 kB ( 7%) ggc early inlining heuristics: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 0 kB ( 0%) ggc inline parameters : 1.06 ( 0%) usr 0.00 ( 0%) sys 1.07 ( 0%) wall 1 kB ( 0%) ggc integration : 0.04 ( 0%) usr 0.00 ( 0%) sys 0.04 ( 0%) wall 0 kB ( 0%) ggc tree gimplify : 5.23 ( 0%) usr 0.04 ( 0%) sys 5.26 ( 0%) wall 38114 kB ( 7%) ggc tree eh : 0.14 ( 0%) usr 0.00 ( 0%) sys 0.14 ( 0%) wall 0 kB ( 0%) ggc tree CFG construction : 0.49 ( 0%) usr 0.02 ( 0%) sys 0.52 ( 0%) wall 13855 kB ( 2%) ggc tree CFG cleanup: 93.20 ( 4%) usr 0.37 ( 0%) sys 93.55 ( 4%) wall 3894 kB ( 1%) ggc tree tail merge : 0.28 ( 0%) usr 0.00 ( 0%)
[Bug tree-optimization/54488] tree loop invariant motion uses an excessive amount of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54488 --- Comment #4 from Evgeniya Maenkova evgeniya.maenkova at gmail dot com --- My gcc version for now: gcc (GCC) 5.0.0 20140908 (experimental)
[Bug tree-optimization/54488] tree loop invariant motion uses an excessive amount of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54488 --- Comment #5 from Evgeniya Maenkova evgeniya.maenkova at gmail dot com --- Also, I collect massif data and see no tree-ssa-lim in it (i mean in top contributors). So what do you think? (How did you measured 1,8Gb caused by lim? - this is for me to understand whether this bug is actual or not) Thanks
[Bug tree-optimization/54488] tree loop invariant motion uses an excessive amount of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54488 Evgeniya Maenkova evgeniya.maenkova at gmail dot com changed: What|Removed |Added CC||evgeniya.maenkova at gmail dot com --- Comment #1 from Evgeniya Maenkova evgeniya.maenkova at gmail dot com --- Could you please clarify this bug status? (As I can see PR46590 you applied some patch that fixes memory issues in Jan of 2014). As I can see from the code (I'm very newbie, sorry for mistakes) there are the structures which keep the information about memory accesses in the whole function (for all the loops). When I read you comment in this bug I started to think there is some possibility to keep the only information about individual loop (which I could try to implement). However, the comment in PR46590 says you meant something different.
[Bug tree-optimization/54488] tree loop invariant motion uses an excessive amount of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54488 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- I had patches to implement the suggestion, work on outermost loops separately. Of course it won't help once you wrap all of them in a single outer loop (which is why I didn't end up committing this). Re-measuring state of current trunk would be still nice (I think we must have improved over the 1GB).