https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44563

Vladimir Makarov <vmakarov at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vmakarov at gcc dot gnu.org

--- Comment #39 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #38)
>
> Seems a lot of memory is taken by IRA, too.
> 
>

I played with the test too.  2^16 functions. It is a lot of insns and IRA/LRA
is not only RA but in some way a code selector too which should keep a lot
additional structures about insns.   Memory numbers for IRA is just GCed memory
allocation.  We should be interesting in *peak* memory allocation.  I don't see
any peak for RA.  ./cc1 -O2 with valgrind massif looks like (after recent
Richard's patch changing IRA XNEWs on a memory pool):


    KB
206.8^                                                            :
     |                                                   :::::#::@:::::@::@:::
     |                                     :::::   ::::::: : :#::@:::::@::@:::
     |                :::::::::::::::::::::::::::::: : : : : :#::@:::::@::@:::
     |               ::::                ::::::::: : : : : : :#::@:::::@::@:::
     |           :@ :::::                ::::::::: : : : : : :#::@:::::@::@:::
     |          ::@::::::                ::::::::: : : : : : :#::@:::::@::@:::
     |          ::@::::::                ::::::::: : : : : : :#::@:::::@::@:::
     |          ::@::::::                ::::::::: : : : : : :#::@:::::@::@:::
     |          ::@::::::                ::::::::: : : : : : :#::@:::::@::@:::
     |          ::@::::::                ::::::::: : : : : : :#::@:::::@::@:::
     |          ::@::::::                ::::::::: : : : : : :#::@:::::@::@:::
     |          ::@::::::                ::::::::: : : : : : :#::@:::::@::@:::
     |          ::@::::::                ::::::::: : : : : : :#::@:::::@::@:::
     |          ::@::::::                ::::::::: : : : : : :#::@:::::@::@:::
     |          ::@::::::                ::::::::: : : : : : :#::@:::::@::@:::
     |          ::@::::::                ::::::::: : : : : : :#::@:::::@::@:::
     |          ::@::::::                ::::::::: : : : : : :#::@:::::@::@:::
     |          ::@::::::                ::::::::: : : : : : :#::@:::::@::@:::
     |          ::@::::::                ::::::::: : : : : : :#::@:::::@::@:::
   0
+----------------------------------------------------------------------->Mi
     0                                                                   1.435

So it is about 200MB *peak* memory consumption and RA consuming only 4% of time
which I think is an excellent result (usually RA takes more time).

 integrated RA                      :   7.21 (  4%)   1.51 (  3%)   9.37 (  3%)
1581592 kB ( 38%)                                             
 LRA non-specific                   :   1.35 (  1%)   0.31 (  1%)   1.95 (  1%)
   3584 kB (  0%)                                             
 LRA virtuals elimination           :   0.38 (  0%)   0.10 (  0%)   0.43 (  0%)
      0 kB (  0%)                                             
 LRA reload inheritance             :   0.16 (  0%)   0.04 (  0%)   0.14 (  0%)
      0 kB (  0%)                                             
 LRA create live ranges             :   0.01 (  0%)   0.01 (  0%)   0.08 (  0%)
      0 kB (  0%)                                             
 LRA hard reg assignment            :   0.23 (  0%)   0.06 (  0%)   0.17 (  0%)
      0 kB (  0%)

Reply via email to