Re: [tree-ssa vs lno] who is right?

[Dale Johannesen <dalej at apple dot com>]

On Mar 26, 2004, at 10:10 AM, Zdenek Dvorak wrote:

> Hello,
>
> > When the LNO branch copies a loop, it attempts to fix up the phi nodes
> > with
> > an algorithm that assumes there is only one phi per block per 
> > variable.
> >  That is, it
> > won't see code like this:
>
>  (i.e. what do you mean by "copying a loop")?

tree_duplicate_loop_to_header_edge (called from unswitching in the 
failing case)

> where do we assume this

lv_adjust_loop_header_phi . The assumption is explicit:

                      /* There can not be second phi node for the same 
variable.
                         Get out of the for loop that walks phi nodes 
of 'first'.
                      */
There isn't any way to find the right phi at that point AFAICT, so I'm 
thinking
along the lines of making sure the phi lists are in the same order when 
doing
the loop duplication earlier (they aren't now).

> While this certainly is unlikely to happen, there probably is nothing
> that would prevent it.

> Zdenek
>
> > ;; basic block 19, loop depth 0, count 0
> > ;; prev block 9, next block 20
> > ;; pred:       10 [100.0%]  (fallthru)
> > ;; succ:       28 [50.0%]  (true,exec) 29 [50.0%]  (false,exec)
> > # maxmin_Result_140 = PHI <1(10)>;
> > # maxmin_Result_142 = PHI <2(10)>;
> > # lsm_tmp.19_144 = PHI <lsm_tmp.19_84(10)>;
> > <L28>:;
> > if (m__10 == 0) goto <L26>; else goto <L27>;
> >
> > Is that suppose to be a valid assumption?  The dup is created by
> > copyrename, and
> > I see no code there that's intended to stop dups from being created 
> > (on
> > the
> > contrary, but surely it's unusual for the live ranges to overlap).