Hi, the patch also solves inliner compile time problems for mozilla: garbage collection : 15.88 ( 4%) usr 0.00 ( 0%) sys 15.89 ( 4%) wall 0 kB ( 0%) ggc callgraph optimization: 3.10 ( 1%) usr 0.00 ( 0%) sys 3.09 ( 1%) wall 15604 kB ( 1%) ggc varpool construction : 0.69 ( 0%) usr 0.01 ( 0%) sys 0.69 ( 0%) wall 51621 kB ( 3%) ggc ipa cp : 1.99 ( 1%) usr 0.08 ( 1%) sys 2.06 ( 1%) wall 123497 kB ( 8%) ggc ipa lto gimple in : 0.04 ( 0%) usr 0.02 ( 0%) sys 0.07 ( 0%) wall 0 kB ( 0%) ggc ipa lto gimple out : 11.70 ( 3%) usr 0.58 ( 8%) sys 12.29 ( 3%) wall 0 kB ( 0%) ggc ipa lto decl in : 318.89 (81%) usr 3.73 (53%) sys 323.19 (80%) wall 722318 kB (47%) ggc ipa lto decl out : 10.45 ( 3%) usr 0.23 ( 3%) sys 10.67 ( 3%) wall 0 kB ( 0%) ggc ipa lto decl init I/O : 0.13 ( 0%) usr 0.04 ( 1%) sys 0.16 ( 0%) wall 31 kB ( 0%) ggc ipa lto cgraph I/O : 1.88 ( 0%) usr 0.26 ( 4%) sys 2.14 ( 1%) wall 433578 kB (28%) ggc ipa lto decl merge : 20.51 ( 5%) usr 0.14 ( 2%) sys 20.65 ( 5%) wall 962 kB ( 0%) ggc ipa lto cgraph merge : 2.43 ( 1%) usr 0.00 ( 0%) sys 2.43 ( 1%) wall 14538 kB ( 1%) ggc whopr wpa : 0.59 ( 0%) usr 0.02 ( 0%) sys 0.62 ( 0%) wall 1 kB ( 0%) ggc whopr wpa I/O : 0.61 ( 0%) usr 1.75 (25%) sys 2.38 ( 1%) wall 0 kB ( 0%) ggc ipa reference : 1.02 ( 0%) usr 0.00 ( 0%) sys 1.02 ( 0%) wall 0 kB ( 0%) ggc ipa profile : 0.16 ( 0%) usr 0.00 ( 0%) sys 0.17 ( 0%) wall 0 kB ( 0%) ggc ipa pure const : 0.85 ( 0%) usr 0.02 ( 0%) sys 0.89 ( 0%) wall 0 kB ( 0%) ggc parser : 0.66 ( 0%) usr 0.00 ( 0%) sys 0.66 ( 0%) wall 10372 kB ( 1%) ggc inline heuristics : 1.22 ( 0%) usr 0.07 ( 1%) sys 1.28 ( 0%) wall 159368 kB (10%) ggc callgraph verifier : 0.11 ( 0%) usr 0.02 ( 0%) sys 0.12 ( 0%) wall 0 kB ( 0%) ggc varconst : 0.02 ( 0%) usr 0.03 ( 0%) sys 0.03 ( 0%) wall 0 kB ( 0%) ggc unaccounted todo : 0.74 ( 0%) usr 0.00 ( 0%) sys 0.76 ( 0%) wall 0 kB ( 0%) ggc TOTAL : 394.08 7.10 401.76 1533113 kB
one second for inlining seems acceptable. There is however growth from 20MB to 159MB of inliner GGC usage. It is because of moving inline_summary vector into GGC memory. ipa-cp summaries seems to have similar footprint as seen above. The problem is that cgraph_node->uid will be sparse after merging. I wonder if we want to solve this by adding new uids to the analyzed nodes that will be denser? Most of summaries are actually attached to the analyzed nodes only. Sadly libxul won't build again for apparently problem: [Leaving LTRANS /abuild/jh/tmp//ccIgav2O.args] [Leaving LTRANS libxul.so.ltrans.out] g++: warning: -pipe ignored because -save-temps specified Reading command line options: libxul.so.ltrans0.olto1: error: ELF section name out of range It seems that for some irrational reason we now decide to stream everything into single partition that is bad idea, but still our ELF infrastructure should not give up. the .o file seems wrong: jh@evans:/abuild/jh/build-mozilla-new11-lto-noelfhackO3/toolkit/library> objdump -h libxul.so.ltrans0.o BFD: libxul.so.ltrans0.o: invalid string offset 4088662 >= 348 for section `.shstrtab' BFD: libxul.so.ltrans0.o: invalid string offset 407 >= 348 for section `(null)' objdump: libxul.so.ltrans0.o: File format not recognized Honza
