This is the mail archive of the
mailing list for the GCC project.
Re: COND_EXPR lowering patch
- From: law at redhat dot com
- To: Andrew MacLeod <amacleod at redhat dot com>
- Cc: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>, gcc mailing list <gcc at gcc dot gnu dot org>
- Date: Tue, 26 Aug 2003 12:31:04 -0600
- Subject: Re: COND_EXPR lowering patch
- Reply-to: law at redhat dot com
In message <1061921823.2217.127.camel@p4>, Andrew MacLeod writes:
>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.
True. But I suspect the overwhelming majority of these cases we'll
catch simply because we run the DCE pass twice, with a cfg cleanup
thrown in between.
ie, the first DCE pass will expose the useless conditions to the cfg
cleanup pass. The last DCE pass will get the chance to wipe out the
dead code exposed after we remove the useless conditionals.
I also don't expect a ton of cascading, though it can certainly happen.
Hmmm. Let's say I'm torn. I think we need more data about what happens
>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...
We run DCE just before the conversion from SSA to normal form. I would not
expect that SSA to normal exposes any dead code. Then again, I could be