------- Comment #45 from hubicka at ucw dot cz 2006-08-21 12:56 ------- Subject: Re: [4.1/4.2 regression] A file that can not be compiled in reasonable time/space
Hi, -O2 times: Execution times (seconds) life analysis : 18.08 ( 3%) usr 0.04 ( 1%) sys 19.42 ( 3%) wall 1120 kB ( 0%) ggc integration : 5.97 ( 1%) usr 0.07 ( 2%) sys 6.13 ( 1%) wall 33701 kB ( 8%) ggc tree PRE : 233.01 (43%) usr 0.46 (13%) sys 241.22 (37%) wall 19480 kB ( 5%) ggc tree SSA to normal : 51.26 ( 9%) usr 0.07 ( 2%) sys 52.62 ( 8%) wall 22 kB ( 0%) ggc expand : 2.62 ( 0%) usr 0.07 ( 2%) sys 9.45 ( 1%) wall 24095 kB ( 6%) ggc PRE : 20.39 ( 4%) usr 0.05 ( 1%) sys 21.70 ( 3%) wall 200 kB ( 0%) ggc regmove : 97.32 (18%) usr 0.17 ( 5%) sys 107.36 (16%) wall 2 kB ( 0%) ggc local alloc : 6.28 ( 1%) usr 0.00 ( 0%) sys 6.29 ( 1%) wall 1480 kB ( 0%) ggc global alloc : 13.12 ( 2%) usr 0.71 (21%) sys 62.79 (10%) wall 13764 kB ( 3%) ggc reload CSE regs : 16.16 ( 3%) usr 0.02 ( 1%) sys 19.21 ( 3%) wall 4783 kB ( 1%) ggc scheduling 2 : 60.85 (11%) usr 0.57 (17%) sys 67.94 (10%) wall 206199 kB (51%) ggc TOTAL : 547.14 3.41 651.49 404467 kB Danny has fix for PRE scheduled for 4.2. Regmove hits again the same predicate function sincle we now produce big basic blocks. This can be fixed rather easilly rather by limiting walk in that predicate or assiging INSN consetuctive indexes. Scheduling has problem moving around linked lists of dependencies and fixing it seems to need to go away from log links and thus it is 4.2 issue too. One detail that just came to mind... All memory consumed in scheduling are log links. Producing 206MB of them for 24MB function is rather dense. Can't we prune them out somewhat perhaps by accounting transitivity (at least in special cases)? The instructions are all really mostly independent, but we apparently lose track of the fact somewhere and producing almost complette tournament apparently. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
