Hi Zdenek,
On Wed, Oct 1, 2008 at 5:19 PM, 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
a) All the computations that were added are still present in the basic
block. i.e all the computations are still present in the form in
which they were added and havent been touched by any of the loop
optimizations passes that run between the scalar evolution pass (i.e the
pass when Part 1 is executed) and the 'loopdone' pass. We go
through the exit basic block and look up each stmt in
changed_stmt_table. If found we lookup the corresponding PHI node in the
phi_node_info link list and decrement its count by 1 (count here denotes
the number of computations added. When count it 0 it means all the
computatins added in the scalar evolution pass have been found in the
same form in the loop done pass such a PHI node can be inserted back in
if 'b' is also true).
So if the ssa_names are infact reused they won't be the same
computations. We do store the statements that were introduced and if
we see a difference in the statements based on the hashes calculated
we don't undo the change.
> -- 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 ? Is there anything else you might
suggest in terms of undoing the transformations from scalar cprop.?
cheers
Ramana
>
> Zdenek
>
--
Ramana Radhakrishnan
