Re: Question re: SSA Aggressive Dead Code Elimination

[law at redhat dot com]

  In message <87d77qbgr1.fsf@cgsoftware.com>you write:
  > You also changed reg 45 into reg 44.
  > And moved around the basic blocks.
  > Any particular reason?
This is coming from a larger test program, but this is the only relevant
code.

The change in register #s is due to no longer needing a new name for the
value computed by insn 95 in block #1.

The change in block #s is just my goof in fixing them after extracting the
RTL from the larger testcase.


  > Actually, it should always select the phi alternative for 1.
  > The jump is unconditional, the code label is in block 1.
  > So the path to the phi is always through block *1*, not 0.
  > Oh wait, do we  jump to the code label insn, or the insn immediately
  > following?
In the original program it is not predictable which way we will jump.  ie,
we don't know if the path will be 0 -> 1 -> 2 or 0 -> 2.  The problem is the
aggressive dead code elimination pass thinks that the conditional branch which
selects one of the two paths is dead and as a result there's only one path
through the cfg, specifically 0 -> 2.

In doing so we get the wrong results because ultimate value we store into r0
in insn 101 is dependent on the path through the CFG.


  > I never paid attention, and looking up label_ref and jump_insn in
  > rtl.texi doesn't tell me which is true.
  > Because if we are supposed to jump to the code label,
  > in effect, your CFG is now
  >    E
  >    |
  >    0
  >  /  
  > 1 -> 2 -> E
  > 
  > Which would be correct
  > If we are supposed to jump to the insn right after, we'll have
  > 
  >   E
  >   |
  >   0
  >    \
  >  1->2 -> E
  > 
  > Which is wrong.
Err, these are totally off-base, and I think you're totally missing the
point behind my question.

jeff