[tree-ssa vs lno] who is right?

[Devang Patel]

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