This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix PR tree-optimization/17724


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]