Hi Zdenek,
[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.
>
>> > -- in case more complex loop transformations were performed
>> > (e.g., loop reversal), the final value of the ssa name might have
>> > changed.
>>
>> Could you give an example for this ?
>
> for (i = 100; i > 0; i--)
> a[i] = i;
>
> transformed to
>
> for (i = 1; i <= 100; i++)
> a[i] = i;
>
> the final value of i was originally 0, now it is 101.
>
>> Is there anything else you might
>> suggest in terms of undoing the transformations from scalar cprop.?
>
> I would probably try to somehow pass the information from scev analysis
> to value numbering, and let PRE take care of the issue,
I do not know the value numbering code or the scev code well enough
to attempt this immediately. I'm trying to see if this intermediate
solution is good enough for the time being.
>
> Zdenek
>
--
Ramana Radhakrishnan
