This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] RFC: Making control flow more explicit
- From: Andrew MacLeod <amacleod at redhat dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Michael Matz <matz at suse dot de>, Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>, Steven Bosscher <s dot bosscher at student dot tudelft dot nl>, Daniel Berlin <dberlin at dberlin dot org>, DiegoNovillo <dnovillo at redhat dot com>, gcc mailing list <gcc at gcc dot gnu dot org>
- Date: 12 Aug 2003 12:15:06 -0400
- Subject: Re: [tree-ssa] RFC: Making control flow more explicit
- References: <200308112314.h7BNEDHb008978@speedy.slc.redhat.com>
On Mon, 2003-08-11 at 19:14, firstname.lastname@example.org wrote:
> In message <Pine.LNX.email@example.com>, Michael Ma
> tz writes:
> >> Very very rarely within the DCE optimizer.
> >Control dependence or postdoms also are necessary in if-conversion and for
> >some edge probability predicators.
> Yup. One of the unaddressed questions in my mind is whether or not it makes
> sense to compute postdoms once early in the SSA path and keep them up-to-date
> through the SSA optimizers or not. We compute them on-demand in a few
> places, mostly in areas dealing with IF removal.
> > Hmm, but maybe you're right and some
> >other form of approximate but faster to calculate form of control
> >dependence is enough.
> It's enough for tree-ssa-dce.c; I have no idea if it's suitable elsewhere.
> Hell, it took me a while to convince myself that what tree-ssa-dom.c was
> indeed safe. It didn't take long to determine that what tree-ssa-dom.c
> does was faster than using true control dependence... Let's call it an
> interesting surprise.
> The good news is that if we want to move to using true control dependence
> that it's a fairly simple change to lift the first few hundred lines out
> of ssa-dce.c and put them in tree-ssa-dce.c and tweak tree-ssa-dce.c to use
Well, the only thing we use the parent/control dependence information
for is removing/keeping control flow stmts. Currently, if there is a PHI
node after the control stmt, we can't remove it anyway.
We let the cfg cleanup routines actually remove control flow most of the
time now, do we not? And I beleive you also wanted a lighter-weight DCE.
So perhaps we ought to invoke DCE with a flag indicating whether to
consider control flow or not.
If you don't want control flow analyzed, DCE could simply assume all
control flow stmt's are necessary, and only looks at other stmts. This
should result in a fairly lightweight DCE. If you do want flow
considered, then we build the pdom info and handle control flow as well
(digging out your old patch perhaps?, although we do build PDOM info on
I suspect we'd only need the flow considered during the very last call
before we go back to normal form. Even then, there is likely to be
deletable flow exposed by SSA->normal as PHI nodes are resolved into
copies or coalesced variables, so maybe we dont even need it then. Just
a cleanup afterwards. Maybe it would be handy to always turn on flow
analysis at -O3 or something...