------- Additional Comments From dnovillo at gcc dot gnu dot org 2005-04-08
21:49 -------
(In reply to comment #18)
> Ugh. The copy we inserted turned out to be totally useless for determining
> that the condition at the end of BB5 is always false. Argggh.
>
> To make this scheme work we'd have to do copy insertions anytime the
> COND_EXPR_COND or SWITCH_EXPR changed. Worse yet, we'd need to call
> rewrite_ssa_into_ssa to keep things in SSA form. Double Ugh.
>
It's a matter of scheduling the passes mostly. The reason you're having a hard
time here is mostly because some of the scalar cleanups haven't run. Suppose
that we do this after FRE and copy propagation. We end up with:
D.15513_11 = insn_10->code;
switch (D.15514_11)
{
case 5: goto <L17>;
case 6: goto <L2>;
case 7: goto <L3>;
case 8: goto <L22>;
case 9 ... 10: goto <L0>;
default : goto <L23>;
}
# SUCC: 22 1 21 3 2 16
[ ... ]
# BLOCK 3
# PRED: 0
<L3>:;
if (D.15521_11 != 7) goto <L4>; else goto <L5>;
# SUCC: 5 (false) 4 (true)
Now, if you insert an assertion of any kind at the start of block #3, you'll get
the elimination you're looking for.
Currently, VRP will not handle this case because of the switch. That is easily
fixable. In TCB, the code I get after VRP is this:
# BLOCK 0
# PRED: ENTRY (fallthru,exec)
# VUSE <TMT.0_7>;
D.1144_2 = insn_1->code;
insn_3 = insn_1;
switch (D.1144_2)
{
case 5: goto L17;
case 6: goto L17;
case 7: goto L3;
default : goto L17;
}
# SUCC: 1 (exec) 3 (exec)
# BLOCK 1
# PRED: 0 (exec)
L3:;
D.1145_6 = D.1144_2;
if (D.1145_6 != 7) goto <L5>; else goto L17;
# SUCC: 2 (true,exec) 3 (false,exec)
[ ... ]
So, it would be a matter of choosing the ordering and arranging for VRP to
handle SWITCH_EXPRs.
Now, if what you want is a design where all these actions are done in one
super-pass, well, that's a different can of worms.
Diego.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15524
