public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeffrey A Law <law@redhat.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: Kazu Hirata <kazu@cs.umass.edu>,
	rth@redhat.com, dnovillo@redhat.com, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Fix PR tree-optimization/17724
Date: Fri, 08 Oct 2004 19:32:00 -0000	[thread overview]
Message-ID: <1097263242.4227.4.camel@localhost.localdomain> (raw)
In-Reply-To: <20041008053138.GQ31909@devserv.devel.redhat.com>

On Thu, 2004-10-07 at 23:31, Jakub Jelinek wrote:
> On Thu, Oct 07, 2004 at 06:15:56PM -0400, Kazu Hirata wrote:
> > Hi Jakub,
> > 
> > > The first patch calls free_dominance_info in cleanup_tree_cfg whenever
> > > delete_unreachable_blocks deleted some basic blocks.  It should be safe, but
> > > might be expensive.
> > 
> > I guess so.  thread_jumps, which is called right after
> > delete_unreachable_blocks in cleanup_tree_cfg, tries to maintain the
> > dominator info, so if you are freeing it, you might want to remove the
> > code to maintain it in thread_jumps.
> 
> Yeah, my preferred patch is 3 (recomputing some dominators in
> delete_unreachable_blocks).  Possibly if that turns out to be too expensive
> when there are too many basic blocks as predecessors or successors of
> unreachable blocks (that aren't unreachable themselves), we could add
> later on some ceiling (the one 3rd of basic blocks below is completely
> arbitrary), e.g.
>   if (nsuccs * 3 > n_basic_blocks)
>     free_dominance_info (CDI_DOMINATORS);
>   else
>     for (i = 0; i < nsuccs; ++i)
>       recompute one by one;
Well, if you want a testcase you might peek at 15524; it's spending
over 20% of its time in the tree CFG cleanup code.  I haven't looked
into what it's doing that is so bloody bad, but it's clearly doing
something goofy (I'm up to my eyeballs in driving down the time for
DOM for that testcase right now :-)

Anyway, the only tidbit I could pass along is that the CFG cleanup
time has basically been unchanged, even with Kazu's recent work.

Jeff


  reply	other threads:[~2004-10-08 19:20 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-07 20:13 Jakub Jelinek
2004-10-07 22:16 ` Kazu Hirata
2004-10-08  7:05   ` Jakub Jelinek
2004-10-08 19:32     ` Jeffrey A Law [this message]
2004-10-08 20:25       ` Andrew Pinski
2004-10-08 23:48 ` Diego Novillo
2004-10-09  8:24   ` Zdenek Dvorak
     [not found] <20041009082440.GB22455@atrey.karlin.mff.cuni.cz>
2004-10-09  9:23 ` Zdenek Dvorak
  -- strict thread matches above, loose matches on Subject: below --
2004-09-30  1:05 Jakub Jelinek

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=1097263242.4227.4.camel@localhost.localdomain \
    --to=law@redhat.com \
    --cc=dnovillo@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=kazu@cs.umass.edu \
    --cc=rth@redhat.com \
    /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).