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

[Devang Patel <dpatel at apple dot com>]

On Mar 26, 2004, at 10:22 AM, Dale Johannesen wrote:

> 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)

I saw this happening couple of days ago at this point in
tree_duplicate_loop...

      /* Add phi nodes for definitions to exit_block (we could find out
         which of them are really used outside of the loop and don't 
emit the
         phi nodes for the remaining ones; for this we would however 
need
         to know immediate uses).  */
      for (arg = usable_outside; arg; arg = TREE_CHAIN (arg))
        {
          def = TREE_VALUE (arg);
          phi = create_phi_node (def, exit_block);
          for (ae = exit_block->pred; ae; ae = ae->pred_next)
            add_phi_arg (&phi, def, ae);
        }

> > 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'.
>                       */

Yes, that's what my understanding was (until this thread). I'm glad I
note down my assumptions.

> There isn't any way to find the right phi at that point AFAICT,

That's what I found at that time... here is what I am trying to do
in lv_adjust_loop_header_phi

/* Adjust phi nodes for 'first' basic block.  'second' basic block is a 
copy
   of 'first'. Both of them are dominated by 'new_head' basic block. 
When
   'new_head' was created by [splitting] 'second's incoming edge it 
received phi arguments
   on the edge by split_edge(). Later, additional edge 'e' was created 
to
   connect 'new_head' and 'first'. Now this routnine adds phi args on 
this
   additional edge 'e' that new_head to second edge received as part of 
edge
   splitting.
*/

-
Devang

> 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).