This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] COND_EXPR lowering preview
- From: law at redhat dot com
- To: Diego Novillo <dnovillo at redhat dot com>
- Cc: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Fri, 29 Aug 2003 13:08:02 -0600
- Subject: Re: [tree-ssa] COND_EXPR lowering preview
- Reply-to: law at redhat dot com
In message <firstname.lastname@example.org>, Diego Novillo w
>On Wed, 2003-08-27 at 15:52, email@example.com wrote:
>> In message <firstname.lastname@example.org>, Diego Novill
>> >On Tue, 2003-08-26 at 14:53, Zdenek Dvorak wrote:
>> >> It disables control structures removal in dce; this also has to be
>> >> handled separately.
>> >What does this have to do with COND_EXPR lowering?
>> A lot actually. If you have lowered COND_EXPRs, then there is very little
>> value in tracking control dependencies in DCE.
>Ah, OK. Is this the thread about not using the control parent
>relationship in DCE?
> 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