public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: rth@gcc.gnu.org To: gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, jason@gcc.gnu.org, rth@gcc.gnu.org, schmid@snake.iap.physik.tu-darmstadt.de Subject: Re: c++/5504: Optimization breaks wei-ku-1 from blitz Date: Wed, 10 Apr 2002 10:42:00 -0000 [thread overview] Message-ID: <20020410174223.16495.qmail@sources.redhat.com> (raw) Synopsis: Optimization breaks wei-ku-1 from blitz Responsible-Changed-From-To: jason->rth Responsible-Changed-By: rth Responsible-Changed-When: Wed Apr 10 10:42:22 2002 Responsible-Changed-Why: My patch. State-Changed-From-To: analyzed->suspended State-Changed-By: rth State-Changed-When: Wed Apr 10 10:42:22 2002 State-Changed-Why: http://gcc.gnu.org/ml/gcc-patches/2002-04/msg00474.html Given enough memory, this solves the compile-time problem. It now takes about 6 minutes to compile instead of 7 hours. Peak memory usage is still atrocious though -- abour 1.2GB; I'm not sure how to solve that, or indeed if it can be solved. EH semantics of goto requires that all of the EH regions be created so that we can bind vs other EH regions at the end. Even if we discover in the middle that there will be no such goto requiring such processing, we'll have already created the rtl, which means that the memory is already in use. Since we can't garbage collect in the middle of rtl generation, peak memory usage will not be impacted by any complex schemes in the middle of code generation. It may be possible to perform an optimization pass in which EH cleanups are removed from the AST before instantiation in rtl. That would indeed positively impact peak memory use. Put that in the indefinite future though... http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5504
next reply other threads:[~2002-04-10 17:42 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2002-04-10 10:42 rth [this message] -- strict thread matches above, loose matches on Subject: below -- 2003-05-09 9:35 reichelt 2003-05-08 22:44 bangerth 2002-04-18 6:46 Jason Merrill 2002-04-05 15:26 Jason Merrill 2002-04-05 15:16 Jason Merrill 2002-04-03 18:26 Diego Novillo 2002-04-03 18:08 jason 2002-03-26 6:46 Diego Novillo 2002-03-22 10:14 jakub 2002-03-22 10:10 jakub 2002-03-22 7:51 dnovillo 2002-03-21 7:12 jakub 2002-03-20 9:36 Peter Schmid 2002-03-18 7:02 jakub 2002-01-26 16:06 Peter Schmid
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20020410174223.16495.qmail@sources.redhat.com \ --to=rth@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ --cc=gcc-gnats@gcc.gnu.org \ --cc=gcc-prs@gcc.gnu.org \ --cc=jason@gcc.gnu.org \ --cc=schmid@snake.iap.physik.tu-darmstadt.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).