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


             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: link
Be 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).