This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Decompose gimplify_expr
- From: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- To: Daniel Berlin <dberlin at dberlin dot org>
- Cc: Diego Novillo <dnovillo at redhat dot com>,Mark Mitchell <mark at codesourcery dot com>,Geoffrey Keating <geoffk at apple dot com>,GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 3 Aug 2005 11:13:24 +0200
- Subject: Re: [patch] Decompose gimplify_expr
- References: <20050722234109.GB23954@atrey.karlin.mff.cuni.cz> <19E23ABC-50D8-4175-92EA-90EAD244653A@apple.com> <20050729190508.GB9128@atrey.karlin.mff.cuni.cz> <42EA84A0.8090103@codesourcery.com> <20050729194953.GA5812@topo.toronto.redhat.com> <20050731163739.GA9114@atrey.karlin.mff.cuni.cz> <1122829989.32467.10.camel@linux.site>
Hello,
> > In any case, I don't intend to implement any complicated optimizations.
> > I definitely will avoid any "special case handling";
> > if the optimization is too complicated, it is hardly worth doing
> > at the expansion time. I will be considering only simple optimizations
> > like unreachable code removal and constant propagation that have
> > a good chance to be very useful and save significant amount of memory
> > and compile time (especially on code that uses macros a lot).\
>
> I will simply note that we have *already* run into issues because things
> like "constant propagation" were added to cleanup_cfg. (It ends up
> causing us to need to update ssa in some cases that it doesn't do, and
> shouldn't have to, since it's a fricking cfg cleanup pass)
constant propagation is not performed anywhere in cfg cleanup. The
reason why ssa form needs to be updated after cfg cleanup is not because
of constant propagation, but because cfg cleanup may delete edges (and
you must delete the edges that cannot be taken somewhere, cfg
cleanup is just the practical place where to do it so that dozen
of other passes does not need to care about it).
Zdenek
> There are always corner cases in simple optimizations that nobody thinks
> about that bite us in the ass later.
>