This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Wed, Oct 15, 2008 at 8:37 AM, Zdenek Dvorak <rakdver@kam.mff.cuni.cz> wrote:
> 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.


I've already hit 2 whilst building with the patch and I agree that
hashing through the uses is going to make compilation very slow. I
don't see an easy option then to add the checks for hashing the SSA
names . Is there something else that I could try ?


cheers
Ramana
>
> Zdenek
>



-- 
Ramana Radhakrishnan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]