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]

Re: Question re: SSA Aggressive Dead Code Elimination




On Wed, 27 Jun 2001 law@redhat.com wrote:

>   In message <Pine.LNX.4.33.0106271319510.30643-100000@www.cgsoftware.com>you w
> rite:
>   >
>   >
>   > On Wed, 27 Jun 2001 law@redhat.com wrote:
>   >
>   > Yeah yeah. I need to think more before writing emails so i don't look
>   > stupid. It usually hits me about 2 minutes later that I was completely
>   > wrong.
> You're not the only one.  What had me worried was that in my current condition
> (rather ill) that I'd missed something important.  After a night of sleep
> things are a lot clearer :-)
>
>   > As to which optimization is wrong, all the dominator optimization did
>   > was eliminate a useless  computation, and reuse a register (in effect,
>   > copy propping a=b+c into  b=b+c to get b=a), which should not change the
>   > importance of the jump node.  It seems to have only because it
>   > copy-propped into a phi node.
> Right.  And I really don't want to cripple the dominator based optimizations
> which appear to be a lot more effective than the aggressive dead code
> elimination (when compared to more traditional dead code elimination).
>

>
>   > The only way this could happen that i can think of is if you weren't
>   > following the control dependences in phi nodes in the dead code
>   > elimination.
> We follow the source regs in PHI nodes and mark their definition sites as
> important.  But that's insufficient in this case as the definition sites
> are both in block 0 due to the copy propagation.

Ahh, here's the kicker. You need to mark the control transfer instructions
from the source blocks in our phi nodes as important too. Or so the
comments in all three compilers say.

The example pass code i pasted claims to be doing it using the
reverse dominance frontier to figure out  which nodes it's really control
dependent on, and marking any of the control transfer instructions in
those nodes as important.
Since we already have the edge pointers, i don't think we need the RDF to
do this, we should just be able to mark the edges based on the alternative
in the phi node.


 >
> As Geoff suggested, I think the way to go is mark the control dependent
> edges associated with each alternative in the PHI nodes as important and
> everything will just fall out.

Yup.
>
> Morgan's book doesn't have any special handling for PHI nodes in the
> aggressive dead code elimination algorithm (nor does Muchnick or
> Appel have special handling of PHI nodes).
>
> jeff
>
>   >
>   > --Dan
>   >
>
>


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