This is the mail archive of the
mailing list for the GCC project.
Re: COND_EXPR lowering patch
- From: Andrew MacLeod <amacleod at redhat dot com>
- To: Andrew MacLeod <amacleod at redhat dot com>
- Cc: Jeff Law <law at redhat dot com>, Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>, gcc mailing list <gcc at gcc dot gnu dot org>
- Date: 26 Aug 2003 14:16:58 -0400
- Subject: Re: COND_EXPR lowering patch
- References: <200308260743.h7Q7hW7s001060@speedy.slc.redhat.com> <1061920989.2168.119.camel@p4>
On Tue, 2003-08-26 at 14:03, Andrew MacLeod wrote:
> On Tue, 2003-08-26 at 03:43, email@example.com wrote:
> > In message <1061855171.25084.327.camel@p4>, Andrew MacLeod writes:
> > >On Mon, 2003-08-25 at 18:00, Zdenek Dvorak wrote:
> > Once you lower COND_EXPRs so that they merely contain a condition
> > and GOTO_EXPRs in their arms, it becomes quite trivial for either
> > linearize_cond_expr or a CFG based jump threader to remove
> > useless COND_EXPRs. Meaning that we will not need control dependency
> > stuff in dce long term (either the real stuff or the stuff we fake
> > using control statement parents).
> Then I'd be tempted to side with Zdenek.. If there isnt a long term
> strategic reason to go to the effort of switching this around to get
> control flow with control dependance info, why not just leave it as a
> simple lightweight DCE? It doesnt buy us much anyway.
Oh, wait, there is a reason to keepo it working I guess. If DCE can
remove the condition, then that can expose other code which feeds the
condition which can be eliminated, which might cause more flow to be
dead that wouldn't otherwise. The other control flow removal bits can't
do that without calling back and forth to DCE.
I'd also be tempted to try to call that final DCE from within
SSA->Normal once we've eliminated PHIs, but before we've actually
written the program back to normal form... Then we could get everything
thats really dead at that point...