[tree-ssa] DCE and conditionals

[law@redhat.com]

In message <1052169493.19625.1284.camel@p4>, Andrew MacLeod writes:
 >On Mon, 2003-05-05 at 16:45, Diego Novillo wrote:
 >> On Mon, 2003-05-05 at 16:33, Andrew MacLeod wrote:
 >> 
 >> > If a_1 and a_0 do not coalesce, then a_5 needs to have a copy on one of
 >> > the 2 branches of the conditional in order to calculate the PHI node. 
 >> > And in order to do that, you have to know what the original condition
 >> > was.
 >> > 
 >> Ah, yes.  So, keep the conditional expression.  After you've brought the
 >> program out of SSA form, run the linearizer once more.  And, this time,
 >> you untie its hands and let it trash COND_EXPRs that have both arms
 >> empty.  Similarly with other empty blocks that couldn't be removed
 >> before because of PHI nodes.
 >> 
 >And then there are the instructions which fed the conditional which may
 >all be dead now too... thats why I want to run DCE again....
 >> 
 >> > And in order for that to be effective, we
 >> > should look at phi removal when possible since thats what ends up
 >> > keeping the conditions alive... 
 >> > 
 >> PHIs that have all their arguments the same can be easily checked in the
 >> linearizer.
 >> 
 >
 >But they aren't the same until I've coalesced them, and rewritten them,
 >and then we are out of SSA form... So having it in the linearizer does
 >do us much good in these cases.
Copy prop along with various edge eliminations can result in cases where
PHI nodes can turn into copies.   There's a couple cases:

  1. All the source operands are the same.

  2. There are two unique source operands, one of which is the same
     as the destination operand.

When I played with this stuff at the RTL level, the only way you'd see
these things occuring was if you allowed overlapping ranges for 
registers in PHI nodes during value numbering/copy propagation.

jeff


PHI nodes
 >
 >Andrew
 >