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 13:02:26 -0600
- Subject: Re: COND_EXPR lowering patch
- Reply-to: law at redhat dot com
In message <1061923315.2168.130.camel@p4>, Andrew MacLeod writes:
>On Tue, 2003-08-26 at 14:31, email@example.com wrote:
>> >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
>It can expose dead control flow, plus anything which ripples from that,
>but perhaps we get that later?
We get a goodly amount of that via the useless statement eliminator.
> We currently cant eliminate flow which has a PHI node in the post
That's no longer entirely correct :-) There are cases where you can
eliminate the flow even when there is a PHI in the post dominator. We've
been doing it in linearize_cond_expr for a month or so. Basically if
incoming edges to the PHI from each arm of the COND_EXPR have equivalent
arguments, then we can remove the COND_EXPR and collapse the two PHI
alternatives into a single alternative. This happens often enough to
>SSA->Normal eliminates all the PHI
>nodes, so these empty control structures become fair game if the
>elements of the PHI node coalesced together and no code was inserted
>into the empty control blocks....
OK. I see. I'm not sure how much this happens now that we collapse
useless control statements, even when there's a PHI in the pdom. If it
still happens, then, yes I see how it would be useful.