[Bug c/87615] Possible excessive compile time with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87615 --- Comment #11 from Martin Jambor --- It's actually, ipa_polymorphic_call_context::get_dynamic_type that causes problems here. I'll prepare a patch.
[Bug c/87615] Possible excessive compile time with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87615 --- Comment #10 from rguenther at suse dot de --- On Tue, 23 Oct 2018, jamborm at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87615 > > Martin Jambor changed: > >What|Removed |Added > > Status|NEW |ASSIGNED >Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot > gnu.org > > --- Comment #9 from Martin Jambor --- > (In reply to Richard Biener from comment #8) > > > > Can any of you fix that please? > > If doing that only in stage 3 is fine, I can. Sure.
[Bug c/87615] Possible excessive compile time with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87615 Martin Jambor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org --- Comment #9 from Martin Jambor --- (In reply to Richard Biener from comment #8) > > Can any of you fix that please? If doing that only in stage 3 is fine, I can.
[Bug c/87615] Possible excessive compile time with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87615 Richard Biener changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #8 from Richard Biener --- (In reply to Jan Hubicka from comment #7) > > Looks like the IPA-CP stmt walking is still unbound? > There is also walking in ipa-fnsummary that is unbound, perhaps that is the > problem... > > Honza Can any of you fix that please?
[Bug c/87615] Possible excessive compile time with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87615 --- Comment #7 from Jan Hubicka --- > Looks like the IPA-CP stmt walking is still unbound? There is also walking in ipa-fnsummary that is unbound, perhaps that is the problem... Honza
[Bug c/87615] Possible excessive compile time with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87615 --- Comment #6 from Richard Biener --- Btw, compiles in 8s with -O1 which is what we suggest for machine-generated code like this.
[Bug c/87615] Possible excessive compile time with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87615 Richard Biener changed: What|Removed |Added Keywords||compile-time-hog Status|UNCONFIRMED |NEW Last reconfirmed||2018-10-16 CC||hubicka at gcc dot gnu.org, ||jamborm at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from Richard Biener --- Confirmed. Looking at GCC 7 (120s compile-time) I see (-ftime-report -ftime-report-details): ipa cp : 0.19 ( 0%) usr 0.00 ( 0%) sys 0.24 ( 0%) wall 8576 kB ( 2%) ggc `- dominance computation: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc `- alias stmt walking : 76.66 (61%) usr 0.07 ( 3%) sys 76.70 (60%) wall 0 kB ( 0%) ggc GCC 8 (180s compile-time): ipa cp : 0.20 ( 0%) 0.01 ( 0%) 0.23 ( 0%) 10168 kB ( 2%) `- dominance computation : 0.02 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%) `- ipa dead code removal : 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 0 kB ( 0%) `- alias stmt walking : 125.65 ( 70%) 0.29 ( 13%) 125.95 ( 70%) 0 kB ( 0%) GCC 9 (240s compile-time): ipa cp : 0.33 ( 0%) 0.00 ( 0%) 0.28 ( 0%) 9657 kB ( 2%) `- dominance computation : 0.02 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%) `- alias stmt walking : 139.23 ( 55%) 0.05 ( 2%) 139.35 ( 54%) 0 kB ( 0%) tree FRE : 49.71 ( 20%) 0.57 ( 24%) 50.25 ( 20%) 1824 kB ( 0%) `- tree CFG cleanup: 0.04 ( 0%) 0.00 ( 0%) 0.06 ( 0%) 0 kB ( 0%) `- loop fini : 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 0 kB ( 0%) `- alias stmt walking : 0.55 ( 0%) 0.00 ( 0%) 0.58 ( 0%) 3 kB ( 0%) the FRE thing is the new value-numbering algorithm. Looks like the IPA-CP stmt walking is still unbound?
[Bug c/87615] Possible excessive compile time with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87615 --- Comment #4 from David Binderman --- (In reply to Alexander Monakov from comment #3) > Looks like gcc-9 regressed here. Not sure. Adding flag -fno-inline to the compile line: $ time ~/gcc/results.265139.release/bin/gcc -w -I ../trunk/runtime -O2 -c -fno-inline destDir/testFile.8458.c real0m47.647s user0m45.990s sys 0m0.473s So it seems that if the inline is switched off, compile time reduces a lot (92%). $ fgrep -c inline destDir/testFile.8458.c 0 $ Doesn't make much sense to me.
[Bug c/87615] Possible excessive compile time with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87615 --- Comment #3 from Alexander Monakov --- On gcc-8 -fno-ipa-cp does not affect time, I brought it up prematurely: -O2 -time # cc1 207.15 0.22 -O2 -time -fno-ipa-cp # cc1 207.57 0.18 -O2 -time -fno-inline # cc1 21.13 0.10 Looks like gcc-9 regressed here.
[Bug c/87615] Possible excessive compile time with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87615 --- Comment #2 from David Binderman --- (In reply to Alexander Monakov from comment #1) > How much does -fno-ipa-cp help (on gcc-8 I see incredibly deep recursion in > walk_aliased_vdefs_1 under IPA-CP analysis)? New execution time is about 8 minutes 50 seconds, so about 10 % reduction. Alias statement walking seems to consume most of the original time.
[Bug c/87615] Possible excessive compile time with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87615 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #1 from Alexander Monakov --- How much does -fno-ipa-cp help (on gcc-8 I see incredibly deep recursion in walk_aliased_vdefs_1 under IPA-CP analysis)?
