Hi,
> >> >> So if the ssa_names are infact reused they won't be the same
> >> >> computations.
> >> >
> >> > do you also check this for ssa names inside the loop (in your example,
> >> > D.10_1?
> >>
> >> If we have to reinsert for a = phi (B) . We do the following checks.
> >>
> >> 1. If the edge information in the phi node has remained the same then
> >> we don't insert the phi node back in. This check is done by running
> >> the phi node applying iterative_hash_expr on its PHI_ARG_DEF_PTR .
> >>
> >> Something like this is done for checking the consistency of hash values.
> >>
> >> 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);
> >>
> >> }
> >>
> >> I suspect that this should catch the case that you mention here.
> >
> > now you have lost me completely -- this does not seem to check anything
> > regarding the computations inside the loop, just about the phi node,
>
> Well since the phi node with a single operand depends on statements /
> operations within the loop, the hashcode computed initially and
> finally need to match. If the computations within the loop change then
> clearly the hash values at the time of storing and restoring would be
> different . So if the assignment to D.10_1 has changed in some form,
> the hashvalues would be different.
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,
Zdenek
