public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "fjahanian at apple dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/20216] [4.0/4.1 Regression] Simple loop runs out of stack at -O1
Date: Sun, 27 Feb 2005 13:06:00 -0000	[thread overview]
Message-ID: <20050227005105.26096.qmail@sourceware.org> (raw)
In-Reply-To: <20050225212929.20216.fjahanian@apple.com>


------- Additional Comments From fjahanian at apple dot com  2005-02-27 00:51 -------
(In reply to comment #6)
> The first part of the patch seems fine.
> We should make tree_fold_binomial non-recursive.
You meant tree_fold_factorial? tree_fold_binomial is not recursive as is.

> Note, however, that once you do that, the other part of the patch isn't actually
> doing anything (the change to chrec_apply).
I agree. checking for 1024 is arbitrary and I did not propose it as a final solution.
I think a better solution would be to compute the factorial of the array upper bound,
as currently is done. If it cannot be evaluated, due to overflow, chrec_evaluate 
which depends on computation of tree_fold_binomial returns chrec_dont_know. In other words, we
do this optimization only when factorial can be computed. This prevents
setting an arbitrary limit and will let the implmentation limitations dicides feasibility
of this optimization. What do you think on a patch along this line?

> 
> Then all the memory usage comes from fold (all 600 meg of memory usage, i mean)
> creating new trees.
> It also doesn't recurse int hat case.
> 
> In any case, limiting the input to chrec_apply to <1024 is uh, wrong, as it's
> not really fixing anything.
> 

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20216


  parent reply	other threads:[~2005-02-27  0:51 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-26 14:26 [Bug tree-optimization/20216] New: " fjahanian at apple dot com
2005-02-26 15:28 ` [Bug tree-optimization/20216] [4.0/4.1 Regression] " pinskia at gcc dot gnu dot org
2005-02-26 16:13 ` fjahanian at apple dot com
2005-02-26 16:25 ` pinskia at gcc dot gnu dot org
2005-02-27  4:32 ` hp at gcc dot gnu dot org
2005-02-27  4:37 ` hp at gcc dot gnu dot org
2005-02-27  8:45 ` dberlin at gcc dot gnu dot org
2005-02-27 13:06 ` fjahanian at apple dot com [this message]
2005-02-27 13:21 ` dberlin at dberlin dot org
2005-02-27 21:03 ` pinskia at gcc dot gnu dot org
2005-03-01  2:44 ` cvs-commit at gcc dot gnu dot org
2005-03-01 15:13 ` [Bug tree-optimization/20216] [4.0 " pinskia at gcc dot gnu dot org
2005-03-01 16:23 ` cvs-commit at gcc dot gnu dot org
2005-03-01 16:28 ` cvs-commit at gcc dot gnu dot org
2005-03-01 17:06 ` pinskia at gcc dot gnu dot org

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=20050227005105.26096.qmail@sourceware.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /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).