This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Fix thinko in cleanup_tree_cfg
- From: Jeffrey A Law <law at redhat dot com>
- To: Andrew Pinski <pinskia at physics dot uc dot edu>
- Cc: Daniel Berlin <dberlin at dberlin dot org>, Diego Novillo <dnovillo at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Fri, 19 Aug 2005 11:27:15 -0600
- Subject: Re: Fix thinko in cleanup_tree_cfg
- References: <200508191659.j7JGx0UN031619@earth.phy.uc.edu>
- Reply-to: law at redhat dot com
On Fri, 2005-08-19 at 12:59 -0400, Andrew Pinski wrote:
> > > Only
> > > vague "It helps redundancy elimination, etc" statements (while at the
> > > same time, it incredibly messes up the CFG in a lot of cases).
> > If you've got cases where it's messing up the CFG, please do pass
> > them along. We have the ability to prune out jump thread requests
> > which do more harm than good. Right now that pruning code is mostly
> > concerned with avoiding creation of irreducible loops, but it can
> > be extended as necessary.
>
> One thing it increases code size too much, even for -Os and -O2.
> See PR 21883 for an example where code size could almost double because
> of jump threading. In fact this was reported two months ago and nothing
> has been done about it. This is a very bad code size regression and really
> does not help with preformance as the one extra branch after a lot of functions
> call is not going to hurt.
This is completely different than the issue Daniel raised of mucking up
the CFG. This is an issue of too much code expansion to save a single
conditional.
Code expansion issues can be easily dealt with by limiting the size of
the blocks we thread through. If this is happening in real code rather
than in a contrived testcase then I'd happily work on it today.
Jeff