This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Bug middle-end/28071] [4.1/4.2 regression] A file that can not be compiled in reasonable time/space


Hi,
update at -O1 few patches later (different machine with "only" 500MB
ram, so some swappin occurs, but we almost fit now):
 life analysis         :  23.50 (20%) usr   0.00 ( 0%) sys  23.51 (17%) wall    2565 kB ( 2%) ggc
 inline heuristics     :   0.60 ( 1%) usr   0.00 ( 0%) sys   0.60 ( 0%) wall    1561 kB ( 1%) ggc
 integration           :   5.75 ( 5%) usr   0.04 ( 2%) sys   5.79 ( 4%) wall   33701 kB (20%) ggc
 tree SSA rewrite      :   0.51 ( 0%) usr   0.01 ( 1%) sys   0.53 ( 0%) wall   17087 kB (10%) ggc
 tree SRA              :   0.98 ( 1%) usr   0.08 ( 4%) sys   1.10 ( 1%) wall   24835 kB (15%) ggc
 tree SSA to normal    :  45.11 (39%) usr   0.02 ( 1%) sys  45.14 (33%) wall      17 kB ( 0%) ggc
 local alloc           :   5.82 ( 5%) usr   0.01 ( 1%) sys   5.85 ( 4%) wall    1855 kB ( 1%) ggc
 global alloc          :   9.83 ( 8%) usr   0.76 (39%) sys  23.49 (17%) wall   11029 kB ( 6%) ggc
 reload CSE regs       :   7.30 ( 6%) usr   0.03 ( 2%) sys  10.16 ( 7%) wall    2393 kB ( 1%) ggc
 TOTAL                 : 116.65             1.96           136.52             170783 kB
Life analysis is almost completely code tracking dead stores after
reload (we have many stack slots).  Tree-SSA to normal is the SRA
problem discussed, integration is split_block, global alloc allocate
very huge conflict matrix, reload CSE regs has similar problem tracking
memories.  No idea about local alloc.

Honza


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]