This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: COND_EXPR lowering patch


On Tue, 2003-08-26 at 14:03, Andrew MacLeod wrote:
> On Tue, 2003-08-26 at 03:43, law@redhat.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...

Andrew


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]