[Bug tree-optimization/54488] tree loop invariant motion uses an excessive amount of memory

2014-10-21 Thread evgeniya.maenkova at gmail dot com 
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

2014-10-20 Thread evgeniya.maenkova at gmail dot com 
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

2014-10-19 Thread evgeniya.maenkova at gmail dot com 
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

2014-10-19 Thread evgeniya.maenkova at gmail dot com 
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

2014-10-19 Thread evgeniya.maenkova at gmail dot com 
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

2014-10-10 Thread evgeniya.maenkova at gmail dot com 
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.