Hi,
> [Sorry about dropping the ball on this. I've had some trouble with
> internet connectivity and was on vacation for a few days. ]
>
> On Thu, Oct 2, 2008 at 2:56 AM, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> >> >> b) If any PHI node has count zero it can be inserted back and its
> >> >> corresponding computations removed, iff the argument of the
> >> >> PHI node
> >> >> still exists as an SSA variable. This means that we can insert
> >> >> a_1 = PHI <D.10_1> if D.10_1 still exists and hasnt been removed by
> >> >> any of the passes between the scalar evolution pass and the
> >> >> loopdone pass.
> >> >
> >> > this does not work:
> >> > -- we reuse ssa names, so it can happen that the argument of the PHI node
> >> > is eliminated, then reused for a different purpose
> >>
> >> I wasn't sure if from the proposal strong enough to catch this case ? i.e.
> >> if
> >>
> >>
> >> 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,
Zdenek
