Re: query regarding adding a pass to undo final value replacement.

[Zdenek Dvorak <rakdver at kam dot mff dot cuni dot cz>]

Hi,

> > but you only take the hash of the argument of the phi node (i.e., the
> > ssa name), not the computations on that it is based
> 
> Is this something like what you had in mind ?
> 
> gen_hash (stmt)
> {
> 
>   if (stmt == NULL)
>     return 0;
> 
>       use_operand_p use_p;
>       ssa_op_iter iter;
>       val += get_changed_stmt_hash (stmt);
>       FOR_EACH_SSA_USE_OPERAND (use_p, stmt, iter, SSA_OP_USE)
>       {
>         tree use = USE_FROM_PTR (use_p);
>         val += get_stmt_hash (use);
>         val += gen_hash (SSA_NAME_DEF_STMT (use));
>       }
>     }
>   else
>     val += generate_phi_node_hashcode (stmt);
> 
> 
>   return val;
> }
> 
> and one calls this in continuation to my earlier email by
> 
> 
>    arg_p = PHI_ARG_DEF_PTR (phi_node , 0);
>    op0 = USE_FROM_PTR (arg_p);
>    val = iterative_hash_expr (op0, val);
>    if (TREE_CODE (op0) == SSA_NAME)
>      {
>        val = iterative_hash_expr (SSA_NAME_VAR (op0), val);
>        val += SSA_NAME_VERSION (op0);
> 
>        val += gen_hash (SSA_NAME_DEF_STMT (op0));

otoh, there seem to be at least four problems with this:

1) The fact that the statement is identical does not mean that
   it also returns the same value (calls, memory accesses, ...).
   I guess one could argue that if FVR succeeded, we should not
   run into such problems, which is a bit shaky reasoning, but
   might actually be the case.
2) You would be hashing everything reachable through the uses,
   which as written will lead to an infinite loop in any program
   with a cycle.  Even if this were fixed, hashing (potentially)
   whole program would be extremely slow.
3) Two different expressions may have the same hash value.
4) SSA_NAME_DEF_STMT (op0) may have been removed, so this would
   be accessing garbage.

Zdenek