This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] COND_EXPR lowering preview
- From: Andrew MacLeod <amacleod at redhat dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Diego Novillo <dnovillo at redhat dot com>, Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>, gcc-patches <gcc-patches at gcc dot gnu dot org>, gcc mailing list <gcc at gcc dot gnu dot org>
- Date: 29 Aug 2003 15:17:48 -0400
- Subject: Re: [tree-ssa] COND_EXPR lowering preview
- References: <200308291908.h7TJ82Gc020872@speedy.slc.redhat.com>
On Fri, 2003-08-29 at 15:08, email@example.com wrote:
> In message <firstname.lastname@example.org>, Diego Novillo w
> > I guess we can always do the traditional DCE and
> >build dominance frontiers in the reverse CFG (Cytron's original
> ?!? No need. We use the same code we have today with a couple changes.
> 1. We mark COND_EXPRs as inherently necessary.
> 2. We remove the code which removes COND_EXPRs from tree-ssa-dce.
> Now there's still an unanswered question -- which of the different DCE
> schemes is actually the most appropriate/fastest.
> We we've got in tree-ssa-dce.c is built around the idea that we'll be
> removing control structures, which I'm pretty sure we're not going to be
> doing in DCE long term. So are there other approaches to DCE which
> are going to have better performance properties and possibly be a little
Is it? If we mark all the control stmts as necessary, and remove our
control flow checking code, you are left with something which seems
fairly minimal to me.. A pass through the IL to see whats needed, and
then visit any stmts which are forced as necessary by other stms which
are necessary... (the worklist). You'd never visit any stmt more than
twice, and you never have to go hunting for anything. control stmts
would never be looked at again.