[Bug lto/49700] LTO compile time hog
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49700 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #9 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-05-08 18:52:12 UTC --- trying 4.7.X instead it actually looks very reasonable now. Using -flto=jobserver -fuse-linker-plugin -ftime-report -O3 -march=native -ffast-math -g -ffree-form I get CP2K to build in 4min on a 32 cores server. The time report also looks OK. I'll close this PR as fixed (to issue with 4.8 is tracked in PR 45586).
[Bug lto/49700] LTO compile time hog
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49700 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-05-07 Ever Confirmed|0 |1 --- Comment #7 from Richard Guenther rguenth at gcc dot gnu.org 2012-05-07 12:38:43 UTC --- Has the situation improved?
[Bug lto/49700] LTO compile time hog
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49700 --- Comment #8 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch 2012-05-07 19:04:29 UTC --- (In reply to comment #7) Has the situation improved? current trunk LTO seems to fail on CP2K with: /data/vjoost/clean/cp2k/cp2k/src/../src/rt_propagation_methods.F: In function ‘propagate_cn_or_em’: /data/vjoost/clean/cp2k/cp2k/src/../src/rt_propagation_methods.F:217:0: error: type mismatch in component reference SUBROUTINE propagate_cn_or_em(qs_env, error) ^ struct array2_integer(kind=4) struct array2_integer(kind=4) # VUSE .MEM_805 D.79093_629 = D.79094_628-orders.data; /data/vjoost/clean/cp2k/cp2k/src/../src/rt_propagation_methods.F:217:0: error: type mismatch in component reference SUBROUTINE propagate_cn_or_em(qs_env, error) ^ struct array2_integer(kind=4) struct array2_integer(kind=4) # VUSE .MEM_805 D.79092_630 = D.79094_628-orders.offset; /data/vjoost/clean/cp2k/cp2k/src/../src/rt_propagation_methods.F:217:0: error: type mismatch in component reference SUBROUTINE propagate_cn_or_em(qs_env, error) ^ struct array2_integer(kind=4) struct array2_integer(kind=4) # VUSE .MEM_805 D.79090_632 = D.79094_628-orders.dim[1].stride; /data/vjoost/clean/cp2k/cp2k/src/../src/rt_propagation_methods.F:217:0: error: type mismatch in component reference SUBROUTINE propagate_cn_or_em(qs_env, error) ^ struct array2_integer(kind=4) struct array2_integer(kind=4) # VUSE .MEM_816 D.79093_652 = D.79094_651-orders.data; /data/vjoost/clean/cp2k/cp2k/src/../src/rt_propagation_methods.F:217:0: error: type mismatch in component reference SUBROUTINE propagate_cn_or_em(qs_env, error) ^ struct array2_integer(kind=4) struct array2_integer(kind=4) # VUSE .MEM_816 D.79092_653 = D.79094_651-orders.offset; /data/vjoost/clean/cp2k/cp2k/src/../src/rt_propagation_methods.F:217:0: error: type mismatch in component reference SUBROUTINE propagate_cn_or_em(qs_env, error) ^ struct array2_integer(kind=4) struct array2_integer(kind=4) # VUSE .MEM_816 D.79090_655 = D.79094_651-orders.dim[1].stride; /data/vjoost/clean/cp2k/cp2k/src/../src/rt_propagation_methods.F:217:0: error: type mismatch in component reference SUBROUTINE propagate_cn_or_em(qs_env, error) ^ struct array2_integer(kind=4) struct array2_integer(kind=4) # VUSE .MEM_827 D.79093_675 = D.79094_674-orders.data; /data/vjoost/clean/cp2k/cp2k/src/../src/rt_propagation_methods.F:217:0: error: type mismatch in component reference SUBROUTINE propagate_cn_or_em(qs_env, error) ^ struct array2_integer(kind=4) struct array2_integer(kind=4) # VUSE .MEM_827 D.79092_676 = D.79094_674-orders.offset; /data/vjoost/clean/cp2k/cp2k/src/../src/rt_propagation_methods.F:217:0: error: type mismatch in component reference SUBROUTINE propagate_cn_or_em(qs_env, error) ^ struct array2_integer(kind=4) struct array2_integer(kind=4) # VUSE .MEM_827 D.79090_678 = D.79094_674-orders.dim[1].stride; /data/vjoost/clean/cp2k/cp2k/src/../src/rt_propagation_methods.F:217:0: error: type mismatch in component reference SUBROUTINE propagate_cn_or_em(qs_env, error) ^ struct array2_integer(kind=4) struct array2_integer(kind=4) # VUSE .MEM_838 D.79093_700 = D.79094_699-orders.data; /data/vjoost/clean/cp2k/cp2k/src/../src/rt_propagation_methods.F:217:0: error: type mismatch in component reference SUBROUTINE propagate_cn_or_em(qs_env, error) ^ struct array2_integer(kind=4) struct array2_integer(kind=4) # VUSE .MEM_838 D.79092_701 = D.79094_699-orders.offset; /data/vjoost/clean/cp2k/cp2k/src/../src/rt_propagation_methods.F:217:0: error: type mismatch in component reference SUBROUTINE propagate_cn_or_em(qs_env, error) ^ struct array2_integer(kind=4) struct array2_integer(kind=4) # VUSE .MEM_838 D.79090_703 = D.79094_699-orders.dim[1].stride; /data/vjoost/clean/cp2k/cp2k/src/../src/rt_propagation_methods.F:217:0: internal compiler error: verify_gimple failed SUBROUTINE propagate_cn_or_em(qs_env, error) ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: gfortran returned 1 exit status /data/vjoost/gnu/binutils-2.22/install/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status
[Bug lto/49700] LTO compile time hog
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49700 --- Comment #5 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-07-12 10:17:54 UTC --- (In reply to comment #3) Oh, so it's a sum ... Well, the I suppose you run into the usual array-prefetching compile-time hog. Try -fno-prefetch-loop-arrays. This seems to reduce the time by 5x. On a non-LTO run, this doesn't matter, but I assume LTO makes more info available that triggers some action by that pass.
[Bug lto/49700] LTO compile time hog
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49700 --- Comment #6 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-07-12 14:40:29 UTC --- (In reply to comment #1) Joost, can you point us to a source tarball? Does the issue reproduce with simpler flags (plain -O2 or plain -O3? Esp. w/o -march=native?) CP2K sources are easy, but the to get a version that links, there are additional non-standard dependencies (blas, lapack, libint).
[Bug lto/49700] LTO compile time hog
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49700 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-07-11 09:20:37 UTC --- The phase parsing :5086.93 (100%) usr 9.45 (100%) sys5213.35 (100%) wall 1072513 kB (100%) ggc line looks completely odd ;) It would be interesting to know what broke the LTO I/O type/merging accounting. Honza? The above is from LTRANS phase, so maybe there's some timevar pushing missing? It looks like materialize_cgraph is suspicious. No, the ltrans object file is of no use. Joost, can you point us to a source tarball? Does the issue reproduce with simpler flags (plain -O2 or plain -O3? Esp. w/o -march=native?)
[Bug lto/49700] LTO compile time hog
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49700 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-11 09:27:50 UTC --- The phase parsing numbers are uninteresting, as lto1 FE does almost all the work in its lto_main (aka parse_file langhook), including cgraph_optimize. So that time includes basically the whole compilation, you can see that the generate phase is very short.
[Bug lto/49700] LTO compile time hog
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49700 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-07-11 09:33:36 UTC --- Oh, so it's a sum ... Well, the I suppose you run into the usual array-prefetching compile-time hog. Try -fno-prefetch-loop-arrays.
[Bug lto/49700] LTO compile time hog
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49700 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2011-07-11 19:56:55 UTC --- Extra diagnostic checks enabled; compiler may run slowly. Configure with --enable-checking=release to disable checks. Also try to build the compiler with that option passed to configure. The defaults for the trunk has always been adding extra checking. CFG verifier: 49.95 ( 1%) usr tree SSA verifier : 376.24 ( 7%) usr tree STMT verifier : 439.42 ( 9%) usr verify loop closed : 168.68 ( 3%) usr As you can see with the above, some verifying takes time (at least 20% of the total time).
