[Bug middle-end/12392] very long optimized compile

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12392 Richard Biener changed: What|Removed |Added Known to fail|| --- Comment #34 from Richard Biener

[Bug middle-end/12392] very long optimized compile

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12392 --- Comment #33 from Richard Biener --- Author: rguenth Date: Wed Mar 30 07:47:40 2016 New Revision: 234546 URL: https://gcc.gnu.org/viewcvs?rev=234546=gcc=rev Log: 2016-03-30 Michael Matz Richard Biener

[Bug middle-end/12392] very long optimized compile

--- Comment #31 from rguenth at gcc dot gnu dot org 2010-06-24 08:42 --- Surely not. g++-4.5 -S -o /dev/null MRApStyle.cc -O2 -g -ftime-report MRApStyle.cc: In constructor ‘MRApStyle::MRApStyle()’: MRApStyle.cc:2409:1: note: variable tracking size limit exceeded with

[Bug middle-end/12392] very long optimized compile

--- Comment #32 from aoliva at gcc dot gnu dot org 2010-06-24 17:58 --- I don't see how a bug reported in 2003 against 3.2 and marked as failing up to 4.0 could possibly be related in any way with VTA. Clearly that bug was fixed. Sure, VTA does perform poorly with these testcases, but

[Bug middle-end/12392] very long optimized compile

--- Comment #30 from aoliva at gcc dot gnu dot org 2010-06-24 04:01 --- Patch installed on 2009-10-01, assuming fixed. -- aoliva at gcc dot gnu dot org changed: What|Removed |Added

[Bug middle-end/12392] very long optimized compile

--- Comment #29 from jamborm at gcc dot gnu dot org 2009-10-01 11:48 --- Subject: Bug 12392 Author: jamborm Date: Thu Oct 1 11:48:24 2009 New Revision: 152368 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=152368 Log: 2009-10-01 Martin Jambor mjam...@suse.cz PR

[Bug middle-end/12392] very long optimized compile

--- Comment #27 from rguenth at gcc dot gnu dot org 2009-09-18 09:45 --- Today we regressed with the introduction of IPA-SRA at -O2 and -O3: ipa SRA : 387.53 (78%) usr 0.08 ( 5%) sys 387.79 (77%) wall 2939 kB ( 1%) ggc my bet is at the alias-oracle walking

[Bug middle-end/12392] very long optimized compile

--- Comment #28 from jamborm at gcc dot gnu dot org 2009-09-18 15:52 --- (In reply to comment #27) Today we regressed with the introduction of IPA-SRA at -O2 and -O3: The problem is that I call compute_inline_parameters() whenever I change a single call site, even when the caller

[Bug middle-end/12392] very long optimized compile

--- Comment #26 from hubicka at gcc dot gnu dot org 2009-03-29 18:48 --- We seem to have regression at mainline today perhaps because of pure-const at -O2: cfg.c:142 (alloc_block)15403008: 2.3% 0: 0.0% 0: 0.0% 0: 0.0% 160448

[Bug middle-end/12392] very long optimized compile

--- Comment #23 from rguenth at gcc dot gnu dot org 2009-02-23 13:43 --- -O2 compile-time improved from ~300s to ~180s over the last 1.5 years. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12392

[Bug middle-end/12392] very long optimized compile

--- Comment #24 from rguenth at gcc dot gnu dot org 2009-02-23 14:16 --- I just timed a-i branch and we get most of the time spent in PRE... PRE : 18.69 (13%) usr 0.25 ( 7%) sys 19.30 (12%) wall 39484 kB ( 5%) ggc 301320 10.8102 compute_transp 104175

[Bug middle-end/12392] very long optimized compile

--- Comment #25 from stevenb dot gcc at gmail dot com 2009-02-23 17:47 --- Subject: Re: very long optimized compile Re Comment #24: I can look into it... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12392

[Bug middle-end/12392] very long optimized compile

--- Comment #22 from steven at gcc dot gnu dot org 2009-02-22 14:15 --- Last modified is long ago. Richi, you added it to the daily testers. How is it doing there? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12392

[Bug middle-end/12392] very long optimized compile

--- Comment #21 from rguenth at gcc dot gnu dot org 2007-09-20 13:56 --- Mainline with release checking now needs -O0: 14.4s 420MB -O1: 202s 520MB tree call clobbering : 32.91 (16%) usr 0.34 ( 9%) sys 33.31 (16%) wall 0 kB ( 0%) ggc tree memory partitioning: 24.84

[Bug middle-end/12392] very long optimized compile

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-18 19:40 --- at -O1 on the mainline, we use over 1GB of memory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12392

[Bug middle-end/12392] very long optimized compile

--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-18 19:52 --- With the C++-initializer cleanup and the gcse.c O(n^2) complexity removal (and ipa-eh) I get on x86_64 at -O2 garbage collection: 2.77 ( 1%) usr 0.03 ( 1%) sys 2.82 ( 1%) wall 0 kB ( 0%)

[Bug middle-end/12392] very long optimized compile

--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-18 19:57 --- Peaks at 514545kB with these patches. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12392

[Bug middle-end/12392] very long optimized compile

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-25 02:01 --- At -O0: function.c:3782 (allocate_struct_function) 825840: 0.6% 0: 0.0%1059120: 7.2% 544544: 3.8% 2618 cfg.c:211 (connect_dest)1989960: 1.5%

[Bug middle-end/12392] very long optimized compile

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-25 02:53 --- at -O1: tree-inline.c:1114 (setup_one_parameter)4402512: 0.3% 0: 0.0% 0: 0.0% 0: 0.0% 122292 gimple-low.c:529 (record_vars) 4410336: 0.3%

[Bug middle-end/12392] very long optimized compile

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-21 04:53 --- With the mainline on ppc-darwin we have a huge problem in the scheduler: scheduling: 131.99 (44%) usr 52.35 (75%) sys 231.63 (46%) wall PRE (GCSE) is also a problem too: PRE