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? > > -- 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, Zdenek
